I’ve developed a bunch of small handlers and tested them all. The script, as it develops, calls them in increasingly nested depth, i.e.; set aVar to Handler_1(Handler_2(Handler_3(x), Handler_4(y))) for example. As I built this up, I got “script doesn’t understand the handlername message”. Putting my in front of the offending handler doesn’t cure the problem and neither does setting variables to deeper results and using those in the expression. Is there a limit to this kind of nesting? How do you make handlers universal? What else can the message mean given that it works in other combinations.
The script is too long to put here. I’m running OS X 10.3.9 and whatever AppleScript version comes with XTools.
I’ve not come up against a nesting limit so far, NovaScotian. Exactly how many handlers have you nested in this way?
From your description, I’d guess that this is actually down to an error number -1708, indicating that the AppleEvent was not handled by any handler. It can occur when a handler name is specified, but no subroutine exists with a corresponding name:
handler_with_no_subroutine()
In a variation of this, a subtle spelling difference between the offending handler name and that of the subroutine can also produce a similar result:
on handler_that_looks_correctly_spelled()
beep
end handler_that_looks_correctly_spelled
handler_that_looks_correctIy_spelled()
To determine your version of AppleScript, try running this:
Thanks, Kai. I solved the problem by putting the handler code into the handler that used it (it was only used twice so really didn’t need to be a handler). None of your suggestions seemed to be the problem, however.
Just one of the occupational hazards of flying blind, I’m afraid.
Without sight of a script, it’s not always easy to second-guess what might be going wrong. However, it may be worth noting that AppleScript treats certain objects somewhat differently at the top level of a script, as opposed to when they are contained by a handler. The value of variables, for example, can persist - unless those variables are declared as local or placed within handlers.
To demonstrate this for yourself, try running each of the following scripts a few times:
local n
try
set n to n + 1
on error number -2753 (* OSAUndefinedVariable *)
set n to 1
end try
n
--> 1
--> 1
--> 1
--> 1
--> 1
on handlerTest()
try
set n to n + 1
on error number -2753 (* OSAUndefinedVariable *)
set n to 1
end try
n
end handlerTest
handlerTest()
--> 1
--> 1
--> 1
--> 1
--> 1
try
set n to n + 1
on error number -2753 (* OSAUndefinedVariable *)
set n to 1
end try
n
--> 1
--> 2
--> 3
--> 4
--> 5
Unexpected consequences may sometimes result if one is unaware of these potential differences in behaviour. Depending on the nature and size of top level variable values, certain issues may surface (when they are automatically saved as part of a script application, for example).
Does any of this this have anything to do with the problems you were experiencing? Hard to say from just a description.
Anyway, glad to hear that you’ve found a workaround.
