On 11 Sep 2008, at 3:25 pm, Seth Willits wrote:
I don't think I understand your question, because I don't see how Cancel is related. If the user cancels the dialog, the callback from the dialog/controller to the calling controller, yields the return code. If the return code wasn't OK/Default then you don't read take on the settings from the dialog.
That's fine for dialogs that just grab a few input values from the user then proceed using that data if the user clicked OK. But it doesn't cover every situation.
In my case, the dialog applies changes to the data model "live" as a preview. This isn't always necessary but for many kinds of dialogs, it is very user unfriendly not to show them the potential effect of the changes they are making. For example, in Photoshop, nearly every effect that needs a dialog to control it has a "preview" checkbox that shows you exactly the effect of the changes you are about to make right back in your original document. I typically do the same for things that have a noticeable impact on the document content. In this sense the dialog is operating like an inspector, but often you need to apply all the changes at once, or not.
Suppose you have something that has a large number - say about 50 - settings that affect all sort of aspects of how a thing appears. I'm working on just such a thing right now, which is what prompted the question. The user works through the settings, seeing what effect each one has, but after a number of "experiments" decides, no, I won't bother with any of it. By hitting Cancel they can undo all those "experiments" at once (or, they could hit "Apply" to commit the changes permanently, just closing the window could cancel). The alternative of setting each property of the data model and letting Undo handle it is also not very user-friendly - they'd have to individually undo every single change they made. Undo grouping doesn't properly solve this problem by the way, because you can't be sure when you need to open and close the groups as the user interacts with your windows. Using a dictionary, the settings are all saved until the user decides to commit them or not. At least, that's what I have found necessary to handle this behaviour so far, unless anyone can think of something more elegant.
cheers, Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
