Re: How do people typically implement dialog controllers?
Re: How do people typically implement dialog controllers?
- Subject: Re: How do people typically implement dialog controllers?
- From: Graham Cox <email@hidden>
- Date: Thu, 11 Sep 2008 15:49:45 +1000
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 (email@hidden)
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:
This email sent to email@hidden