Just got this problem from a customer. The following code from @mattneub’s “AppleScript - the definitive guide” runs in the Script Editor and fails in Script Debugger:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
property args : null
script s
on run {what, what2}
display dialog what & space & what2
end run
end script
script Trampoline
property parent : s
continue run args
end script
set args to {"howdy", "there"}
run Trampoline
The problem appears to be that the change to the args property value is not being picked up in script s's run handler. If I change the property declaration to a global variable declaration then the script works:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
global args
script s
on run {what, what2}
display dialog what & space & what2
end run
end script
script Trampoline
property parent : s
continue run args
end script
set args to {"howdy", "there"}
run Trampoline
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
property args : {"null", "null"}
set args to {"howdy", "there"}
run Trampoline
script s
on run {what, what2}
display dialog what & space & what2
end run
end script
script Trampoline
property parent : s
continue run args as list
end script
First post here. I hope I’ve got the code formatting right.
When the script’s compiled in Script Debugger, the script objects appear to have different copies of ‘args’ from the main script. Presumably these come from different stages of the compilation process.
If ‘trampoline’ is rewritten so that it’s instantiated at run time instead of during compilation …
script
property parent : s
log args
log my args
continue run args
end script
set Trampoline to result
… the script works as expected. However, the two log commands I’ve added show that there are two versions of ‘args’: the one just set in the main script and another inherited from ‘s’, which was inherited by ‘s’ during compilation. If ‘s’ is made a run-time object too, both ‘args’ values are the one from the main script.
If a property’s intialised to the script itself, the value and the script aren’t recognised as being the same in a script compiled by Script Debugger, although they are with Script Editor.
property thisMe : me
thisMe = me
--> false in Script Debugger.
--> true in Script Editor.
If the script also contains compiled script objects, their parent is the object in ‘thisMe’, not the finally compiled script.
property thisMe : me
property args : null
script s
on run {what, what2}
display dialog what & space & what2
end run
end script
script trampoline
property parent : s
continue run args
end script
set thisMe's args to {"howdy", "there"} -- thisMe's args, not args or my args.
run trampoline
[quote=“ShaneStanley, post:5, topic:653”]
Interesting. I wish I had a time machine to try these in (considerably) earlier versions of both apps.[/quote]
I don’t have a time machine, but I do a bit of scripting in OS 8.6 and 9.0.4 in the SheepShaver emulator. So I tried this:
By the way, I am the customer who launched this avalanche
My notion is similar: Matt Neuburg set this up under Tiger (OS X 10.4.2 and 10.4.3) and Script Debugger 4 beta (presumably 3.0.9). Either we deal with a bug in AppleScript AFTER Tiger and SD does not know about it (Smile and ScriptEditor accept the script with no demur at all), or there is a tiny bacterium in Script Debugger.
Am I wrong?
Apparently so. Mark has explained in another thread that SD uses its own OSA component to compile scripts so that it can install debugging hooks as required. The anomaly’s presumably something to do with this.
While code should work (or not) in the same way whatever the editor, it has to be said that this particular script is itself somewhat pathological, designed more to amaze the reader with the possibilities of inheritance than to do anything useful.
‘continue run args’ is a hack to run a script with parameters, which can’t be done with a straight ‘run’ command. And it only works here because ‘args’ is a property of the top-level script. Otherwise it won’t even work in Script Editor unless written ‘continue run (get my args)’. The following works with both SD and SE:
script s
property args : missing value -- Property of script object.
on run {what, what2}
display dialog what & space & what2
end run
end script
script Trampoline
property parent : s
continue run (get my args)
end script
set Trampoline's args to {"howdy", "there"} -- or set s's args to {"howdy", "there"}
run Trampoline
There is of course a StandardAdditions command which can run a script with a parameter:
script s
on run {what, what2}
display dialog what & space & what2
end run
end script
set args to {"howdy", "there"}
run script s with parameters args
But it’s more usual to call a handler in the script object than to run the object itself:
script s
on handle({what, what2})
display dialog what & space & what2
end handle
end script
set args to {"howdy", "there"}
tell s to handle(args)
So although the Script Debugger anomaly must strictly be regarded as a bug, it may actually never inconvenience well-written scripts.
Just to clarify a little bit – Script Debugger uses its own OSA component only when compiling with Debugging on.
The way ASObjC Explorer compiles is using a method in the OSAKit framework. This is a relatively high-level interface, compared with the traditional Carbon interface (OSACompile()), and the only variable factors are the component instance used and some storage options. I’m 99.9% sure Script Editor uses the same.
The Carbon interface, on the other hand, exposes more mode flags, both documented and undocumented, and the mode flags used by Script Debugger are probably where the difference lies.