Re: Quit Application doesn't send window close methods
Re: Quit Application doesn't send window close methods
- Subject: Re: Quit Application doesn't send window close methods
- From: Lance Bland <email@hidden>
- Date: Wed, 1 Jan 2003 10:14:17 -0500
On Wednesday, January 1, 2003, at 09:15 AM, Ted Lowery wrote:
Hi again-
Thanks for the help, this worked. I don't want to start a flame war
here, but I do have an opinion that I want to share and see if it is
off base.
I notice when I look at the docs for -applicationWillTerminate, it says
The applicationWillTerminate: method does not get called for logout for
power off. See NSWorkspaceWillPowerOffNotification, which is sent for
these events. Now this strikes me as [insert flame target here].
Seems if the window is going to close, it should consistently send the
same messages, so as a programmer, I don't have to build a state
machine which captures all the different ways this could happen.
What's to keep the framework from adding something in a future release
that adds yet another way a window can be closed with yet a different
delegate method.
Is this too much to expect from a 10+ year old framework? Is there a
good reason why the framework would not send -windowDidResignKey EVERY
TIME, regardless of the instigator?
hi-
You will probably want two distinct ways of being notified of the
different events.
For example, within the method that accepts the notification
NSWorkspaceWillPowerOffNotification you can use -[NSWorkspace
extendPowerOffBy:] to extend the time to power off the computer and
after a certain time you may want to force terminate the app without
saving window (document) content. You may not want to do that for a
simple termination of an application. Under such circumstances, and
others, document windows do not have to resign key window or change any
state.
That said, extendPowerOffBy: is documented as not implemented and
NSWorkspaceWillPowerOffNotification is really a logoff notification
(last time I checked?) as well as a poweroff notification. The
"concepts" of these notifications have been slow to evolve in the past
6 years or so and it hasn't always been consistent from version to
version or platform supported and the mix between notification and
delegation isn't always clear (enough for me).
In general, I think it is better to supply many different notifications
and let the programmer implement the details, instead of the other way
which would not provide resolution for different features.
What's to keep the framework from adding something in a future release
that adds yet another way a window can be closed with yet a different
delegate method.
If there is a good reason to add another method then it has to be done.
Notifications can be added and binary compatibility can be maintained.
It is just that your app won't process them, but that make sense.
-lance
------------------------------------
Lance Bland
mailto:email@hidden
VVI Is The #1 Visual-Report Tool Developer For Mac OS X
http://www.vvi.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.