Re: Quit Application doesn't send window close methods

FROM : Lance Bland
DATE : Wed Jan 01 16:14:17 2003

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_removed>
VVI Is The #1 Visual-Report Tool Developer For Mac OS X
http://www.vvi.com
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.