Re: Closing windows bearing sheets
Re: Closing windows bearing sheets
- Subject: Re: Closing windows bearing sheets
- From: Kurt Revis <email@hidden>
- Date: Mon, 4 Mar 2002 18:12:40 -0800
On Monday, March 4, 2002, at 05:05 PM, email@hidden wrote:
Hmm. Famous last words.
Oh, I know. Fortunately, none of this is likely to lead to anyone's
hasty demise :)
What if Apple decides the right way to fix the problem is to "handle"
the open sheet somehow, and they put the code to do this downstream
from where -windowShouldClose: gets called, basically saying "well, if
the window should close but it has a sheet on it, then let's choose the
default action for the sheet" or some such. Maybe the Kit will
introduce some idea of "cancellable sheets" where sheets you run have
standard ways of getting backed out if the user takes a larger action,
like clicking a close box, that implies they no longer are interested
in the issues presented by the open sheet. Maybe some of the standard
sheets (like NSDocument's save sheet) will support this notion, but
won't be given the chance to back out because your code will
short-circuit the process before they get a chance to act.
What if Apple extends the concept of sheets to include some standard
*non-modal* sheets (like the color picker becoming a non-model sheet
you can pull down into your window and keep up as long as you want, or
something). Now your windows won't close anymore when they have one of
these non-modal sheets in them, unlike the windows of all the other
Cocoa apps out there that didn't use your workaround code.
Etc. etc.
Good examples of what could go wrong. Here's my analysis:
* In the worst case for all those situations, an app using the
workaround will still basically work--it'll just require sheets to be
manually closed sometimes. That's clunky, but we put up with worse
things right now.
* In the worst case right now, without the workaround, you can get your
app into a state where it's confused and can't be quit, just by
option-clicking one close box.
Of course anything can happen--something could change for the worse and
cause the workaround to cause a terrible crash--but I think that's
fairly unlikely, and so I prefer the workaround. That's just my
opinion, and everyone should evaluate the risk/benefit ratio for
themselves. If you choose not to use the workaround, I certainly respect
that decision. (But if someone asks for a workaround, I'm still going
to share what I know.)
Since the Cocoa API lacks a formal specification, we all have to make
educated guesses and tradeoffs, even when writing normal
(non-workaround) code. It seems that Apple could break just about
anything with any release in the future, and there's not a whole lot we
(as application developers) can do about it. All we can do is try to
balance between coding defensively and doing what's actually needed to
get things to work. C'est la vie.
--
Kurt Revis
email@hidden
_______________________________________________
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.