Re: Called script won't store property
Re: Called script won't store property
- Subject: Re: Called script won't store property
- From: kai <email@hidden>
- Date: Mon, 28 Feb 2005 18:34:03 +0000
On Sun, 27 Feb 2005 21:28:53 -0700, Doug McNutt wrote:
At 23:34 +0000 2/27/05, kai wrote:
When you open a script application manually, it is automatically
saved when it quits. This evidently doesn't happen with the run
script command, which I suspect is similar to running a copy in
memory.
Does that suspicion mean that the run script behaves like a "source"
command in tcsh or the equivalent in bash?
All I do know is this, Doug: The run script command often acts on text
(either within a script or from a text file). I wouldn't expect it to
return modified property values to a string or a text file - so I don't
see why it should do something different with a script application. I
would have thought some other action would be needed to store modified
values.
The following does nothing to change the value of the main script's
property 'p':
---------------------------------
property p : "main script"
set s to "set p to \"script s\""
display dialog p --> "main script"
run script s
display dialog p ----> "main script"
---------------------------------
Can the script being "run" have a name conflict with a variable in the
calling script? Must a script expecting to be called be careful to use
"my" directives for localization?
Not (so far as I can see) in the way a script object might do:
---------------------------------
property p : "main script"
script s
set p to "script s"
end script
display dialog p --> "main script"
run s
display dialog p --> "script s"
---------------------------------
However, if the script object has a property of its own, with the same
name as the main script, the issue doesn't arise:
---------------------------------
property p : "main script"
script s
property p : missing value
set p to "script s"
end script
display dialog p --> "main script"
run s
display dialog s's p --> "script s"
display dialog p --> "main script"
---------------------------------
Since the 'load script' command loads a script as a script object, it
seems reasonable to expect it to behave in a similar way.
Incidentally, the following is a better version than my previous
suggestions to Rachel, since it works here in its simplest form:
---------------------------------
set scriptFile to alias "path:to:required:script.app" -- modify as
required
set s to (load script scriptFile)
set scriptResult to run s
store script s in scriptFile replacing yes
display dialog scriptResult
---------------------------------
Can the called script modify a property defined in the calling script?
A global?
---------------------------------
global p
set p to "main script"
set s to "set p to \"script s\""
display dialog p --> "main script"
run script s
display dialog p ----> "main script"
---------------------------------
There was a question about c-like #includes recently and there was no
real solution. Is the called script really being included as opposed
to being executed as a stand-alone application? Does "running a copy"
imply that the called script is getting recompiled?
No. That's not what I meant when I said "*similar to* running a copy in
memory". It was merely an attempt to keep the explanation simple.
Do properties in the called script revert to the original "missing
value" as it is executed or does it remember the value set when it was
last double-clicked?
The latter (here).
Is there a good way to distinguish, in a script, whether it was "run"
or double clicked?
From within the script? Not to my knowledge. We might run a comparison
with the Finder's selection property but, as we already know, that's
risky to say the least.
Nevertheless, we can observe a difference when something like this is
included in the "calledApplet".
-------------------------
tell application "Finder" to set myName to name of (path to me)
display dialog "This script is being run by " & myName & "."
--> [on double-clicking the "calledApplet" file:] "This script is being
run by calledApplet."
--> [on running script from the "callingApplet":] "This script is being
run by callingApplet."
-------------------------
Is it different if , instead or "run script", you "tell application
called_Script to run" ?
The command 'tell application "called_Script" to run' will probably
fail due to an absence of an application event dictionary. I guess most
other variations involving a tell command might also fail with
something like: "called_Script doesn't understand the run (or even run
script) message".
Anyone have a definitive reference to offer? Suspicion is NOT the best
basis for bug free code.
No, it's not - but I'm only offering suggestions, based upon
observation and testing, that work here. (Hopefully, you're not
suggesting that we shouldn't try to help someone on that basis.) I
don't consider myself an expert in these matters, and my use of the
word "suspect" was intended to convey just that. Now someone may well
come along and shoot me down in flames on all this - and that's just
fine. Then we might all learn something from the exercise. ;-)
However, my main point is that using 'run script' is quite different
from using 'load script' & 'store script'. I just don't think it's wise
to confuse them.
(Oh yeah... one final caveat: I'm currently testing in 10.2.8 - so your
experience may vary.)
Best wishes,
---
kai
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden