Re: Load Script
Re: Load Script
- Subject: Re: Load Script
- From: Axel Luttgens <email@hidden>
- Date: Sat, 04 Jun 2011 10:31:02 +0200
Le 3 juin 2011 à 21:15, Luther Fuller a écrit :
> The last time I commented on this, about a week ago, I was sure that both the properties and handlers of the calling (parent) script were available in the called (child) script. But, today, when a child script needed a property in the parent, I got an undefined variable error.
>
> When I first said that properties were inherited, I has done experiments confirming that. The experiment scripts have since been trashed.
>
> Today, I searched "AppleScriptLanguageGuide.pdf" for info and found this on page 65 ...
>
> The previous example demonstrates an important point about inherited properties: to refer to an inherited property
> from within a child script object, you must use the reserved word my or of me to indicate that the value to which
> you’re referring is a property of the current script object. (You can also use the words of parent to indicate that the
> value is a property of the parent script object.) If you don’t, AppleScript assumes the value is a local variable.
> For example, if you refer to vegetable instead of my vegetable in the changeVegetable handler in the previous
> example, the result is "Spinach". For related information, see “The it and me Keywords” (page 40).
>
> So I tried it. Nothing. Using variations on a theme with or without the phrases 'my', 'me' or 'of parent' make no difference at all. OR ... Is there some small item I'm missing?
Hello Luther,
You are considering a "caller script" calling a "called script", and I already suggested several times throughout the thread that this doesn't imply a parent/child relationship. The fact that you sometimes could reach the caller's properties doesn't mean that this has been through inheritance...
Save this one as lutherA.app, but keep it open in AppleScript Editor (ASE):
property name : "dontcare"
display dialog (run (load script alias ((path to desktop as text) & "lutherB.scpt")))
and save this one as lutherB.scpt on the desktop:
my name
When run in ASE, lutherA.app raises a dialog displaying "AppleScript Editor", and double-clicking the applet raises a dialog displaying "lutherA".
In both cases, the script objects defined by lutherA.app and lutherB.scpt live side-by-side with common parent(s) and clearly, even when run as an applet, lutherA.app isn't the parent of lutherB.scpt: lutherA.app's property would otherwise have been found through the "inheritance chain". [1]
"Hey, your demonstration is flawed because you are using a pre-existing property!".
OK, let's try this one:
-- lutherA.app:
property foobar : "dontcare"
display dialog (run (load script alias ((path to desktop as text) & "lutherB.scpt")))
-- lutherB.scpt
my foobar
Again, lutherA.app errors both in ASE ("Can't make foobar into type reference") and as an applet ("Can't get foobar").
Now, let's consider a slight variant:
-- lutherA.app:
property foobar : "docarenow"
display dialog (run (load script alias ((path to desktop as text) & "lutherB.scpt")))
-- lutherB.scpt
foobar
It "works" now, both in ASE and as an applet: one gets a dialog displaying "docarenow".
The reason should be clear now.
To be sure:
-- lutherA.app:
property foobar : "docarenow"
display dialog (run (load script alias ((path to desktop as text) & "lutherB.scpt")))
-- lutherB.scpt
DoThat()
on DoThat()
global foobar
return foobar
end DoThat
Again, lutherA.app works as expected both in ASE and as an applet.
So, no inheritance nor an inherited property, just a global variable and AppleScript's legendary inclination to merge properties and globals when searching symbols at the top-level script object.
And yes, global variables are indeed a means for loaded script objects to share data. [2]
To avoid the "inheritance illusion", it would probably be less misleading to be explicit about the intent and to write:
-- lutherA.app:
global foobar
set foobar to "docarenow"
display dialog (run (load script alias ((path to desktop as text) & "lutherB.scpt")))
-- lutherB.scpt
DoThat()
on DoThat()
global foobar
foobar
end DoThat
HTH,
Axel
[1] Note that the environments provided by ASE and the applet differ slightly, as the latter somehow leaks and allows to call handlers defined in the caller script:
-- lutherA.app:
property name : "dontcare"
display dialog (run (load script alias ((path to desktop as text) & "lutherB.scpt")))
on DoThis()
end DoThis
-- lutherB.scpt
DoThis()
my name
Above lutherA.app errors in ASE ("«script» doesn't understand message DoThis") but finds the definition of DoThis() when run as an applet. Frankly, notwithstanding the uncleaness of an object depending on its caller, I wouldn't rely on that "feature" provided by the applet environment.
[2] For example:
-- lutherA.app:
display dialog (run (load script alias ((path to desktop as text) & "lutherB.scpt")))
-- lutherB.scpt
global foobar
set foobar to "docarenow"
run (load script alias ((path to desktop as text) & "lutherC.scpt"))
-- lutherC.scpt
global foobar
foobar
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden