Re: does windowDidClose or not?
Re: does windowDidClose or not?
- Subject: Re: does windowDidClose or not?
- From: Sherm Pendley <email@hidden>
- Date: Sun, 16 Apr 2006 20:46:10 -0400
On Apr 16, 2006, at 8:15 PM, Ben Dougall wrote:
windowWillClose is before it has closed so there may be still a
text field in mid edit -- that's possible isn't it? and maybe the
current edit state is not acceptable (according to a formatter or
particular validation) so would need further editing by the user.
so in that situation going to work on the input data at
windowWillClose point will be too early.
Sounds to me like you want both -windowShouldClose: and -
windowWillClose:. Check the input state and such in -
windowShouldClose:, and only return TRUE if everything is kosher.
That way -windowWillClose: will never get called if the edit state is
not acceptable.
I haven't tested it, but I've a hunch that text fields will have
automatically been finalized, and that NSFormatters have already done
as much as they can to validate the input, by the time that -
windowShouldClose: has been called. So you shouldn't need to worry
about a window being closed in mid-edit, or with some pending input
that a formatter could have caught.
The only thing you really should need to check for is anything that
you *couldn't* catch with a formatter.
if there were a windowDidClose i wouldn't need to consider the mid
edit possibility at all because once the window has closed there
can not possibly be any editing going on.
If there were a -windowDidClose:, it would be called too late to do
what you want to do.
The window has already been closed - how would you retrieve values
from its controls? Okay, let's assume that the window has been moved
offscreen or something, and not yet released. If the current edit
state is invalid, what would happen at that point? You'd have to move
the window back onscreen to open a sheet or correct the bogus input.
What the user would see is a window that closes, then immediately
reappears - not a good user experience.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden