Re: Stay-open applet - problems on quitting
Re: Stay-open applet - problems on quitting
- Subject: Re: Stay-open applet - problems on quitting
- From: kai <email@hidden>
- Date: Thu, 13 Nov 2003 13:52:09 +0000
Ah - I see I'm back on the elite unsubscription rota - otherwise my previous
version of this would have appeared a while back. I just knew they wouldn't
be able to ignore me forever. ;-)
(Sorry for any potential duplication...)
on Thu, 13 Nov 2003 12:41:15 +1100, Richard Morton wrote:
>
I'm working on a stay-open applet which is causing me grief when
>
quitting. It's a long story & has taken a lot of debugging to nail
>
down, but basically what I've discovered is that when the app is quit
>
via Cmd-q, it enters its 'quit' handler immediately, regardless of
>
whatever else it's doing. This is happening under OS10.2.6, AS1.9.1.
>
>
Where it bites me is if it's asked to quit when in the middle of
>
executing its 'idle' routines, which can take some time. It appears to
>
stop what it's doing, execute 'quit' then go back to where it was in
>
the idle routines. My quit handler zeros out the variables the idle
>
handler was using, so the idle handler then errors out.
>
>
My questions are:
>
>
Is this the way it's supposed to work?
I wouldn't have thought so Richard. At least - the force-quit response is
obviously not how I'd expect an *application* to behave. But whether that's
an engineering or a scripting issue is another matter...
I've just tried comparing the behaviour in OS 9.1 (AS 1.8.2) and OS 10.2.8
(AS 1.9.1).
In OS 9, it seems impossible to execute a quit during an idle routine.
Repeated key pressing has little effect. The quit command doesn't even
appear to queued - so I have to wait until the script is between idle
handler operations before I can execute a quit.
In OS 10.2.8, the quit command is registered immediately, but the script
continues to complete execution of the idle handler. The quit routine then
continues once the last idle handler command has been completed.
Of the three behaviours, the one immediately above seems to be the most
desirable in the situation you've described.
Since pre-Panther event handling is supposed to be LIFO, I imagine there's
some other built-in routine that takes care of this when an idle handler is
present. (Perhaps this was introduced post 10.2.6?) From 10.3 (for which I
can't currently test), I guess handling of events on a FIFO basis could also
have an effect. (It's probably more complicated than that - but what do I
know?.)
Then there's the potential scenario in which one may actually *prefer* to
interrupt a lengthy but non-critical idle routine - in which case some sort
of flagging/checking technique might still need to be introduced...
>
Either way, can anyone suggest a robust method for dealing with the
>
behaviour?
>
>
I know I can set flags, but I'm not sure it's the best way & haven't
>
yet found the correct spot for them either. Checking whether the
>
variables have been initialised seems like a kludge - if it errors
>
during initialisation they won't be set, so I'd need an extra trap for
>
that. It also doesn't strike me as a way of dealing with it close
>
enough to the problem - I'd like to find a more general solution if
>
possible.
Short of upgrading, I suppose you could use a repeat loop (albeit somewhat
belt'n'braces) to make sure the flags don't end up waving in the wrong
direction...
-----------------------
property idleOn : false
property quitOn : false
on run
repeat until not quitOn
set quitOn to false
end repeat
-- do other run stuff
end run
on idle
repeat until idleOn
set idleOn to true
end repeat
-- do other idle stuff
set idleOn to false
if quitOn then quit
600 -- or whatever
end idle
on quit
if idleOn then
set quitOn to true
else
-- do other quit stuff
continue quit
end if
end quit
-----------------------
---
kai
_______________________________________________
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.