Re: Newbie Questions: Differences between idle handlers and other type of handlers?
Re: Newbie Questions: Differences between idle handlers and other type of handlers?
- Subject: Re: Newbie Questions: Differences between idle handlers and other type of handlers?
- From: Paul Berkowitz <email@hidden>
- Date: Mon, 24 Feb 2003 08:22:24 -0800
On 2/24/03 5:52 AM, "Simon Brown" <email@hidden> wrote:
>
Oops, brain failure... The above should have read:
>
Direct calls to to the quit{} handler from within the idle{} handler caused
>
the script to perform the commands in the QUIT{} handler up to the "continue
>
quit" command but then return to the line after the quit{} statement and
>
then continue execution of the idle handler.
>
Don't make it a quit{} handler. It's a quit handler (no braces). It's
distinctive in that it can be triggered by a user choosing to quit from the
application menu, cmd-Q, or dock (in OS X). It only works immediately if
that happens during an idle period (i.e. when no script commands are being
carried out). The script will then carry out whatever commands are contained
in the quit handler, then continue quit if so told, and quit. But if you
specifically _call_ a quit handler from elsewhere in the script, it will
indeed go back to where it was and continue on until the end of the script
(or end of the idle handler if called from there). If there are
circumstances under which you want it to quit _immediately_ after running
the quit handler, do it this way:
global quitNow
set quitNow to false
-- to-level script (or run handler)
on idle
--do stuff
if somethingOrOther then
quit
end if
if quitNow then error number -128 -- will quit immediately
--more stuff
return 60 - or whatever
end idle
on quit
--do clean-up stuff
set quitNow to true
continue quit
end
Only include the quit handler if you want to take care of things when the
user quits from menu, dock or cmd-Q. If all you want is to direct an
immediate end-of-script via error number -128, you don't even need a quit
handler. A quit handler simply _intercepts_ user quit actions - that's all
it does. It doesn't actually quit. (Similarly, an idle handler doesn't idle-
it's what happens when you're _not_ idling - sort of 'on non-idle' handler.)
The simplest way of all to quit immediately is to press command-. which is
also an "error" and cuts things short.
Also beware the horrible bug I discovered a couple of months ago. If you
include a quit handler, and also have 'store script' anywhere in your
script. the running script is likely to be dumped into the _other_ script
file (the one called by 'store script') replacing the latter's own script
utterly, and not saved to its own shell (file) when it quits, leaving
properties unchanged. Calling the Finder in the quit handler guarantees
this mess 100% replicable, but it happens less consistently, but just as
frighteningly, regardless. This was in OS 10.2 with a _non-stay-open_ applet
(which shouldn't even allowing user quitting but does so in OS X, not in OS
8/9). But i wouldn't trust it elsewhere either without a lot of testing. I
haven't actually tested it with stay-opens and idle handlers - perhaps it
doesn't happen there.
--
Paul Berkowitz
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.