I found that this Applescript works with Script Debugger when not in debug mode, but in debug mode creates an error “The variable debugText is not defined.”
if debugLogEnable and (1 < ctrCollName) then set debugText to ("smart album \"" & nbrTargetCollName & "\" in " & thisCollKind_S & " \"" & thisCollName & "\"")
The error seems incorrect because it occurs when debugLogEnable is false, and the set statement should not be executed, and also because a variable should not have to be defined to assign a value to it.
Breaking up the statement resolves the problem, Script Editor Debugger no longer has an error.
if debugLogEnable and (1 < ctrCollName) then
set debugText to ("smart album \"" & nbrTargetCollName & "\" in " & thisCollKind_S & " \"" & thisCollName & "\"")
end if
Is there any guidline or cheat sheet regarding parts of the Applescript Language not supported in Script Editor’s debug mode?
I cannot reproduce any error. I started with this test case:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
set debugLogEnable to true
set ctrCollName to 2
set nbrTargetCollName to "aaa"
set thisCollKind_S to "bbb"
set thisCollName to "ccc"
if debugLogEnable and (1 < ctrCollName) then set debugText to ("smart album \"" & nbrTargetCollName & "\" in " & thisCollKind_S & " \"" & thisCollName & "\"")
This runs correctly with and without debugging enabled. I then tried moving it into the context of a handler to see if there was some sort of local variable issue:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
on testing()
set debugLogEnable to true
set ctrCollName to 2
set nbrTargetCollName to "aaa"
set thisCollKind_S to "bbb"
set thisCollName to "ccc"
if debugLogEnable and (1 < ctrCollName) then set debugText to ("smart album \"" & nbrTargetCollName & "\" in " & thisCollKind_S & " \"" & thisCollName & "\"")
end testing
testing()
Again, it runs with and without debugging enabled.
Hi Mark
I did a safeboot to try reset some of the OS just in case. The error still reproduces for me.
I attach a grab of Script Debugger’s error message, a grab of the Script Debugger when it has failed, and a grab of Script Debugger when I set a breakpoint at the line it has failed at.
Hi Mark
The previously uploaded script is incomplete because it refers to Libraries, which are not included.
Here is a version with the Library code included in the file, and no Library references.
The behaviour now changes slightly, the same error is now attached to the next line “end if”
I’ve been able to reproduce the problem. My simplified test case looks like this:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
on testing()
local debugText
set debugLogEnable to false
if debugLogEnable then set debugText to "Something"
return 1234
end testing
testing()
The problem is that when debugLogEnable is false, debugText never gets assigned a value meaning that it does not exist and the instrumentation code SD uses to get the value of the debugText local variable fails.
Solutions:
Do as you’ve done, and put the set debugText to ... statement within a then-endif block .
Ensure that debugText has some value (i.e. exists) before the if statement.
I’ve filed a bug at our end, but frankly this probably isn’t something we can address as the instrumentation code we use to get the value of local variables is created at compile time before the truth of if statement’s expression is known. Making the instrumentation code more defensive will slow debugging further and create even more hidden code bloat.
Hi Mark
Thanks for checking this out. I won’t be able get to this for a couple of days, but I think this is a reasonable decision to avoid code bloat and optimize performance.
If I understand correctly the constraint Is that within a single line if-then block all variables in the “execution” part should be defined, even if not executed. I can work with that, it’s much easier now that I can define the constraint.
@ccstone The fix is a reaivley minor issue. One can also set the variable to null or “”.
The key issue is understanding the tool’s limitations.
The debugger is a tool to help discover and correct errors in the code, and if it injects additional errors, those errors get confused with the real code errors, and prevent evaluation of the real errors (those that occur when the debugger is not running).
Adding the fix when you have 10 lines of code and one small handler is no big deal. When your dealing with over a thosand lines of code, 10 or more handlers and a call stack 5 or 6 layers deep, you want to understand why and how this works fix it systematically rather than fix it when found.
