Works in Script Editor, not in Script Debugger


(Mark Alldritt) #1

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

Any ideas?


(Shane Stanley) #2

Weird. FWIW, osascript seems happy with it.


(Ed Stockly) #3
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

Odd


(Nigel Garvey) #4

Hi.

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

(Shane Stanley) #5

Welcome, Nigel.

Interesting. I wish I had a time machine to try these in (considerably) earlier versions of both apps.


#6

[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:

property thisMe : me
thisMe = me

Script Editor 1.1.3: true
Script Debugger 3.0.9: true

So something happened after 3.0.9. I’ve got another question about 3.0.9 but I’ll put it in a different thread.


(Shane Stanley) #7

Thanks. The plot thickens…


#8

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?


(Nigel Garvey) #9

Likewise ASObjC Explorer.

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.


(Shane Stanley) #10

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.


#11

I think, I learned a lot through this discussion (pathology can be very instructive).
Thanks!


(Nigel Garvey) #12

Thanks, Shane! Plus an extra sentence to make the server accept this post.