Need Better Understanding of Modal Delegates
Need Better Understanding of Modal Delegates
- Subject: Need Better Understanding of Modal Delegates
- From: Jerry Krinock <email@hidden>
- Date: Sat, 17 Feb 2007 15:14:29 -0800
- Thread-topic: Need Better Understanding of Modal Delegates
Several times I've run into a design dead end like this with modal
delegates:
Example: (Saving a Document)
I have a "save:" method to handle saving my document. It returns an
error/result because some senders (for example, AppleScript's
handleCloseScriptCommand: with NSSaveOptionsYes) require an error/result.
However, if the document has no path, "save:" first creates a NSSavePanel,
and then runs it with beginSheetForDirectory:file:modalForWindow:etc:etc.
But then "save:" continues on and returns to the sender immediately, before
there is an error/result to return!
Now, in this particular case, I "solved" the problem by sending the panel
the message -runModalForDirectory:file: instead of
beginSheetForDirectory:file:modalForWindow:etc:etc. Instead of leaving a
didEndSelector to finish the job and continuing on its merry way,
runModalForDirectory:file: blocks until the user dismisses the dialog, so
I've got the error/result.
But instead of giving me a nice sheet, runModalForDirectory:file: gives me a
dialog box instead. The sheet made more sense, cosmetically.
Obviously, I don't understand the theory on which this stuff is built. Why
does the simple cosmetic change from a dialog box to a sheet require such a
fundamentally different method? And how can I design a "save:" method to
run an NSSavePanel sheet and return an error/result?
Thanks,
Jerry Krinock
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden