Re: Stay-open applet - problems on quitting
Re: Stay-open applet - problems on quitting
- Subject: Re: Stay-open applet - problems on quitting
- From: Richard Morton <email@hidden>
- Date: Fri, 14 Nov 2003 11:05:47 +1100
On Friday, November 14, 2003, at 12:52 AM, kai wrote:
Ah - I see I'm back on the elite unsubscription rota...
Only nice people get onto this, obviously. :)
...otherwise my previous
version of this would have appeared a while back. I just knew they
wouldn't
be able to ignore me forever. ;-)
Maybe you were trying to post something with chevrons in it. I've
heard it's illegal in some states now. ;)
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...
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...
That's about how I remember it.
Apart from this problem, the multi-tasking in X brings a dramatic
improvement to the operation of stay-open script apps. I find they can
do much more, with much less interruption to other things.
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.
From your later post:
The point may be obvious - but I neglected to mention that, if the quit
handler changes the value of a property, the change is also registered
immediately. This could clearly affect any idle handler operations
that use
the property. (Handy for checking a quit flag - but otherwise
potentially
unwelcome.)...
That's what I'm seeing here. And finding unwelcome.
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?.)
Likewise. If I'm understanding it correctly though, I figure that FIFO
event handling would fix this particular problem.
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...
It's moot now, but I'd still argue that the system shouldn't override
the app like it does here.
Either way, can anyone suggest a robust method for dealing with the
behaviour?
Short of upgrading...
This is no problem for me, but the project is something I'm hoping to
release and I'd prefer not to make it 10.3 only.
...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 while quitOn
set quitOn to false
end repeat
-- do other run stuff
end run
[...]
This looks really good kai - thanks - I appreciate your time & thoughts
I can't test it right away - work is pressing - but I'll report on the
final outcome.
Luke Wacious & Hinn De Rance
LOL!
Rick O'Shay
_______________________________________________
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.