has wrote:
Axel Luttgens wrote:
1. Enquire about your context pollution
problems on LNS's SD mailing
list and/or their support desk. If SD is the culprit as you
suspect
(it's definitely not AS's doing), [...]
it could well be that he doesn't face context clashes due to SD, just an
old standard AS behavior that gets often overlooked when doing trials
in SE.
That behavior may be described by this rather elusive excerpt from the
ASLG: "The default parent property for any script that doesnít
explicitly declare one is the default target applicationóusually, the
application that is running the script, such as the Script Editor".
Yes, you're (semi) right. AS reports the script's parent as
'AppleScript' so any operation not handled by the script is passed to
the AppleScript component to deal with. I simply reported this without
thinking any further. However it's not the whole story as the
AppleScript component itself can delegate operations to another target,
one specified by the host process. My bad for forgetting all about this
bit - it's not like I don't know my way around OSA well enough by now,
so I must have just been asleep at the wheel at that point.
In fact, I knew you knew the fact. ;-)
Just haven't been able to say it better than through that
"often overlooked".
The default delegate for the AppleScript component is
actually determined by the host process, which usually assigns itself
for convenience. This isn't an AS feature, however, it's an OSA
feature. And how it gets used is decided by the application, so I was
right that it's not AS's doing - it's the application's.
I just wanted to speak about an old behavior encountered with
applets since we are enjoying AS on the Mac.
Thanks for having pointed my too elliptic locution.
So, let's see if this makes some sense
with the "run script" command.
[snip code]
Your demonstration doesn't work as-is because lib.scpt never loads
sublib.scpt (presumably an oversight in the posted code). Easily fixed
by putting the 'load script' line into the test() handler though.
Damn! You are (once again) right!
I first started with "load script" statements, until I re-read
Scott's and your posts, so that I reorganized my scripts so as to use
"run script" statements instead; and then got lost with my copy/paste
operations (just forgot to replace "load" by "run" as well).
These are the scripts I was using:
A sub-library (saved as SubLib.scpt)
====================================
property SomeProp : "Initial value from SubLib"
return me
on test()
display dialog "From SubLib: " & SomeProp
display dialog "From SubLib: " & parent's SomeProp
end test
A library (saved as Lib.scpt)
=============================
property SomeProp : "Initial value from Lib"
property SubLib : ""
set SubLib to run script alias "Path:To:SubLib.scpt"
return me
on test()
SubLib's test()
display dialog "From Lib: " & SomeProp
display dialog "From Lib: " & parent's SomeProp
end test
A main script
=============
property SomeProp : "Initial value from Main"
property Lib : ""
set Lib to run script alias "Path:To:Lib.scpt"
test()
on test()
Lib's test()
display dialog "From Main: " & SomeProp
end test
Sorry for the inconvenience to those who may have tried and just
ended with numerous interrogations marks. :-(
Anyway, here's a much simpler version of the same test:
Simpler, yes, but a one-level version only.
It also misses another point: above example illustrates an
opposite (inversed) approach to the one that seems to be adopted by
Scott.
------- lib.scpt -------
property x : "lib"
on test()
display dialog "" & parent's x
end test
------------------------
------- main.app ------
property x : "main"
set lib to load script alias "MacHD2:Users:has:test:lib.scpt"
lib's test()
------------------------
As you say, running main in a script editor results in the expected
error when AS tries to evaluate "parent's x". Running main.app as an
applet results in a dialog saying "main", which is makes no sense, but
I think I see what's going on.
What appears to be happening in the applet is that lib.scpt is
delegating the 'parent's x lookup' to the AppleScript object. The
AppleScript object is unable to resolve this lookup itself, so it
delegates it to the default target application - the applet shell. The
applet shell automatically delegates it to its main script to take care
of, because forwarding all property lookups and handler calls to an
embedded script what applets are designed for. The same test fails in a
script editor, because script editors aren't designed to do that.
Hmm... (again ;-) )
Lib.scpt
========
on test()
display dialog (parent's properties as list)
end test
Main
====
set Lib to load script alias "Path:To:Lib.scpt"
Lib's test()
When I run Main into SE, I get:
(error dialog) Impossible de désigner {characters 1 thru
88 of document "Main", "Script Editor", true, "2.0",
application} comme string.
Clearly, SE has somehow been promoted to Lib.scpt's parent.
And, according to such an interpretation, asking for SE's SomeProp (as
in my initial example) thus must result in an error.
Interestingly enough, it also fails for a
bundle-based applet, though at the moment I don't know why.
Basically you've found a loophole that exists due to the way some
applet implementations use OSA to do their thing. Although it should be
regarded as a bug (feel free to file a report on it), not a feature,
and its deliberate use avoided.
A bug, I'm not sure.
This is after all consistent with the available language specification,
and persists through every incarnations since System 7.
But clearly, I too don't like that idea of having "libraries"
(implemented as script objects) depending on parent properties
(whatever that parent might be).
[...] ([...], and I can certainly vouch for the
latter.)
I'm wondering why :-)
Axel
|