Re: Can't quit from Dock or cmd-Q
Re: Can't quit from Dock or cmd-Q
- Subject: Re: Can't quit from Dock or cmd-Q
- From: Paul Berkowitz <email@hidden>
- Date: Fri, 25 Oct 2002 17:45:09 -0700
On 10/25/02 12:54 PM, "has" <email@hidden> wrote:
>
>
To answer this question: 'continue quit' DOES work and is most certainly
>
NOT ignored. It just doesn't work the way you're _assuming_ it should. You
>
seem to believe 'quit' to be the ultimate instant application killer. It is
>
not. Continuing quit does _not_ cause your application to shut down
>
immediately, as I previously attempted to explain [1].
>
>
Try my example script with the following modification:
>
>
on quit
>
display dialog "Bye!" buttons {"OK"}
>
set _stop to true
>
continue quit
>
end quit
>
>
Save it as an applet (it doesn't matter which sort), run it and see what
>
happens. Next, comment out the 'continue quit', save, and run it again. As
>
you'll see, 'continue quit' does work. More importantly, you should realise
>
why it's necessary to include it whenever you intercept the 'quit' event.
>
>
Let us know if this stuff finally clicks for you. (I'm not sure what I can
>
say to explain it any better, but I'll give it another try if you're still
>
unsure.)
It's your explanations that sometimes tend to create the obfuscations, has,
because they're too long, as a rule, and too full of petty admonitions,
leading to impatience in the reader. My fault, I'm sure.
Omitting 'continue quit' in your (somewhat contrived) example leads to the
"Bye" dialog appearing twice before quitting. That must mean that simply
coming to the natural end of the script (which occurs when _stop is no
longer false) sends another, implicit, 'quit' command to the script so it
runs around its quit event handler a second time. Whereas leaving in
'continue quit' elides that second 'quit'. OK, that's very interesting and
you've made your point.
But it doesn't have too much bearing on my present situation. I accept that
non-stay-open applets should not offer "Quit" from the dock or application
menu or cmd-Q, and that's the "bug" that they do in OS 10.2. But given that
they do, the user is more likely to "Quit" than to cmd-. or force-quit. And
if they do, then I want the script to quit, after tidying up, and NOT
continue to its natural end, second quit or not. i want it to QUIT. a such,
my own method:
on quit
set _stop to true -- optional due to Errorhandler
my ErrorHandler"", (-128)
-- continue quit -- makes no difference
end quit
--same handler as when any error occurs, incl. cmd-.
on ErrorHandler(errMsg, errNum)
set _stop to true
(* various clean-up operations here *)
if errNum \= -128 then
display dialog errMsg
end if
error number -128
end ErrorHandler
is much cleaner than anything else on offer, and the final error number -128
makes 'continue quit' redundant since it cuts the Gordian knot anyway.
However, the fact that I don't need need 'continue quit' in this
circumstance, and the second fact that 'continue quit' on its own, without
both the ErrorHandler or setting global variable _stop to true doesn't
actually quit, does not change the fact that - as you were at pains to point
out - 'continue quit' does actually do something and is not ignored. it just
doesn't do anything useful for me this time, but may be useful some other
time.
I won't mind at all if the "bug" is "fixed' so that "quit" is no longer
available to users. But as long as it is available, my method is the one
that works to do what _I_ want. I'm sure it's long been known to many other
scripters. nevertheless I did figure it out on my own, so that's why I said
"I figured it out". That was an odd thing to fault me for. I never claimed
to be the first. Anything that is logical will be discovered by many people
at different times.
--
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.