ASOC: Part of object specifier (?) is lost in debug mode?

Script Debugger
#1

The following sort of code fails to work in debug mode. Not sure whether anything can be done about this?

use framework "Foundation"
use scripting additions

local theResult
tell application "iTunes" to set theResult to its tracks
return 0

lib.png786Ɨ574 107 KB

1 Like
#2

Thank you for reporting this bug in the debugger. I have been able to resolve this problem in the upcoming Script Debugger 6.0.1 release.

#3

Thatā€™s awesome! :smile:

#4
#5
#6

Just to be completely on the safe side, although Iā€™m assuming this is the caseā€¦ the fix will also enable code such as the following to be debugged, correct? I.e. with the list of object specifiers returned by a run script command and used as the parameter in a handler call. Thanks! :slight_smile:

use framework "Foundation"
use scripting additions


tell application "iTunes" to my handle(run script "tell app \"iTunes\" to tracks")

on handle(tracks)
    return name of first item of tracks
end handle
#7

This code works in as much as you can step through the statements in the debugger and see the value of the tracks variable. However, the use of the run script command prevents Script Debugger from exploring into the returned object specifiers. This is actually an AppleScript issue, but suffice to say that you will have a better debugging experience dealing with object references that do not originate from a run script command:

tell application "iTunes"
	my handle(tracks)
end tell

on handle(tracks)
	return name of first item of tracks
end handle

If you use this version, and step into the handle handler youā€™ll notice how the items of the tracks array can be expanded to view their properties.

#8

I realize my version using ā€˜run scriptā€™ is a somewhat convoluted construct. But as long as it will be possible to execute and step through the code I posted in debug mode, then thatā€™s perfectly fine (i.e., while that would be the icing on the cake, I donā€™t necessarily need to explore the contents of each object originating from the return value of the run script command in my case). Iā€™m using run script so as to be able to build object specifiers with where clauses etc. at runtime, simplifying my code and giving me a tremendous speed advantage over other alternatives Iā€™ve tried or managed to think of so far. :grimacing:

I was also somewhat irritated with AppleScript at first as to why the application specifier of the current application instead of iTunes was utilized for the returned object specifiers whenever I didnā€™t include the outer tell clause for iTunes. But it does work exactly as I expect it to now, outside of Script Debuggerā€™s debug mode at this point.

#9

Although Iā€™m surprised the ā€˜liveā€™ objects using the correct application specifier are shown in the result pane (for non-ASOC scripts) but not in the variables pane with the variable declared as local? But I suppose the results pane simply gets its content unchanged from AppleScript without whatever is messing up the debugger, resulting in the change of application specifiers, being involved in the process? Anyway, just a curiosity. Iā€™m already happy as can be that the original issue that this thread is about will be fixed. :slight_smile:

sdshot.png1138Ɨ655 266 KB

#10

Yes, the mechanisms used to extract global and local variables are very different, and use of the run script command denies Script Debugger access to some critical information within the AppleScript instance used by the run script command.

1 Like