I’m loading and calling one script from within another script and am having some difficulties getting it to behave exactly as I want it to. One thing that would really help is some way to check if a particular handler exists in the script that I’ve loaded. The distinction between an empty handler (or a handler that has no return value) and an undefined handler is important and in the case of standard handlers (run, open, quit etc) no error will be thrown if the handler is not defined, so there’s no obvious way to tell.
If the script was text (.applescript) then I could probably read it as text and parse it to look for the handler but for compiled scripts I can’t see any way. Is it possible at all? Or are other dynamic programming things possible, such as modifying a script at runtime to add a handler or something?
That your get no errors is because when compiling your script, the missing handlers will be added. All loose code inside yoru object will be placed in the run handler, the quit handler and open handlers will be added with a default value into the script as well. So it make sense you’ll get no error at all.
Also you can’t get a list of all handler names of an script object. but you can test if a handler exists very easy
try
set x to anObject's anotherHandler
on error
set x to null --handler doesn't exists
end try
script anObject
on aHandler()
return true
end aHandler
end script
Right, but that doesn’t work for the default handlers because they’re actually always present, is that right?
That script you put will return the handler object itself (if it exists) - can you get a reference to a default handler?
yes that’s right. A run handler for instance is always present even if you don’t see it. All code will be collected and put into a run handler if it’s not presented.
I think you mean return something else than “null”? Yes you can I use a lot of passing functions to other functions through variables. little example
on functionA()
return {a:null}
end functionA
set x to functionA() --will return the result of the function
set xRef to functionA --will return a reference to thefunction but doesn't execute it
--now we can call the function through the reference
xRef()
I was totally expecting to be disappointed when I started this topic
But what I meant was exactly the same thing that you posted earlier to get a reference to “aHandler”, but instead getting a reference an event handler like run, open, idle, or quit.
try
set x to anObject's open -- this doesn't work
on error
set x to null --handler doesn't exists
end try
script anObject
on open names
-- do stuff
end open
end script
Anyway, I’m pretty sure it’s not possible (the difference is that “aHandler” is a handler but “run” is an event) so I’ll leave that alone. I don’t have time right now but later I’ll post exactly what I’m doing to see if anyone has any other ideas for how to solve it.
Okay, I’m kind of in the wrong forum now but here’s the story…
I’ve made great use of the trick with Automator Runner to add progress bars to my applets but was excited to hear that Lion would support ASOC within AppleScript Editor. However I later stumbled over to Mac OS X Automation where some example “Cocoa-AppleScript Applets” are being hosted and discovered I had been misled. I was very disappointed to learn what it really is: nothing but a shoddy ASOC application wrapper around a script file. I could have made this myself right here on Snow Leopard, and probably could have done a better job too! Instead though I decided to try an ASK version, just to see how well it would work (btw if there’s any similar thing anyone else has made before, let me know). I’m reasonably happy with what I’ve got so far but, just like the ASOC one, I’m having trouble with quitting.
Here’s my Test Applet, which just displays a progress bar. Open it in AppleScript Editor to see the main script, then show bundle contents and open the other script file to see what’s going on behind the scenes. The problem, as noted in the comments, is that the quit handler may get run twice in a row. One idea I had for doing it differently was to support the “should quit” handler rather than the “quit” handler, but this would rely on knowing whether or not the main script had “should quit” defined: If not defined then the app should quit, but if it is defined and simply returns no value, then it shouldn’t quit. So any suggestions regarding any of this would be welcome
(The real issue is that I can’t tell whether a “should quit” event received by Application.scpt has come from the user trying to quit the app or from main.scpt calling continue quit. If there was some way to determine this I’d have no problems.)
P.S. If I’ve made no sense whatsoever in this post, please let me know
