I tried to send this message once before but I don't think it all got
through. Here it is again.
Mark Schonewille:
****
When you use the Quit menu item, Mac OS X sends an event to
Revolution. You can catch this message with the AppleEvent handler or
the shutdownRequest handler. On Mac OS X, I prefer to use the
AppleEvent handler most of the time.
If you use either the AppleEvent handler or the shutdownRequest
handler without a pass command, the application will not quit by
itself (you can also lock messages and issue the quit command).
When you press command-Q, the Quit menu item should work just like
when you use the mouse to select this menu item and you can catch the
AppleEvent and shutdownRequest messages again. However, your script
may catch the commandKeyDown message. If you don't pass this message
with the pass command, your application may not quit.
There are versions of Revolution that don't pass the commandKeydown
message because of a bug. There are also versions that don't pass the
AppleEvent message.
If you are using Rev 2.8.1, problems with quitting are probably due
to a script.
****
You seem to be right.
After much experimentation in a small test stack, I find that, in a
standalone:
1. choosing "quit <myApp> from the "myApp" menu triggers the
shutdownrequest handler, which can block the quitting, but the
closestackrequest is not triggered at any time. And the menuPick
"quit" in the File menu script is *not* triggered, it's completely
ignored (contrary to what Devin suggested (and what I would expect)).
2. command-q also triggers the shutdownrequest handler but not the
closestackrequest as in (1), and it never triggers my
"commandkeydown" handler.
So in these two cases it appears that the commandkeydown and menupick
handlers are ignored. (!?)
3. Clicking the closebox at the top left of the window does *not*
trigger the shutdownrequest handler at all, but does trigger the
closestackrequest handler, which can block the close.
All of these ways of exiting the app finally trigger the closestack
handler (unless the closing process is blocked by the other
handlers), but -- if I put an "answer" command at the beginning of
the closestack handler (ie, answer "triggered closeStack") only the
closebox operates the way I would expect. That is, clicking the
closebox brings up the dialog and waits for me to click "OK" then
executes other commands in the closeStack handler and finally closes
the app. The other two open the answer dialog then go on without
pausing to run the other commands in the closeStack handler -- the
next ones include an ask file command, and that dialog appears in
front of the still-open "triggered closestack" dialog, but the ask
file dialog waits appropriately for input, then the rest of the
commands are executed and the app summarily closes (ignoring the
still-open answer dialog), even if an "exit to top" is one of the
further commands. So the system is definitely intruding on the rev
scripting here in some way, causing Rev to ignore what would
otherwise be blocking commands. ???
So it appears that if I want to perform any last save of my data, I
*could* put those commands in the closestack handler. But the failure
to wait for the button click on an answer dialog seems like a bug to
me -- what if I need to use an answer dialog in my shutdown routines?
As it happens, for the stack I'm working on now I don't need this,
but I sure will in the future.
The alternative is to put the same shutdown routines in both the
closestackrequest and the shudownrequest handlers, which covers the
bases no matter how the user quits the app. Which is what I will do,
I guess. All of this does seem excessively complex, though, and not
at all well-documented. What do other people do to handle their
closing routines? This must be a common need, so I imagine that there
are well-established ways of handling it. Input would be appreciated.
I'm still trying to figure out why my actual RecipeFile stack doesn't
respond at all to either cmd-q or the RecipeFile > 'quit RecipeFile'
menuitem. It's acting as though the shutdownrequest were not passed.
But my shutdownrequest handler does indeed pass the shutdownrequest
message at the end of a bunch of housekeeping stuff. Could an error
in those housekeeping routines somehow derail things so the "pass"
command is never reached?
Sorry to go on and on about this stuff but it's really hanging me up
and if I don't understand it I'll never be able to make workable apps
from Rev.
-- Peter
Peter M. Brigham
[EMAIL PROTECTED]
http://home.comcast.net/~pmbrig/
-- To err is human, but to really foul things up you need a computer.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
