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: Seth Willits <email@hidden>
- Date: Thu, 11 Sep 2008 12:27:22 -0700
On Sep 10, 2008, at 11:53 PM, Graham Cox wrote:
In Photoshop CS2 (which I have), previews are always within the
dialog itself. In that case, it seems logical to me to make a
temporary copy of your model for the dialog to modify and display
as it needs. However, it sounds as if that isn't what you're
describing; You want the controls in the dialog to modify the
visible model in the *document* window.
It may have changed since I last used it much, but they used to have
a local preview in the dialog AND a live preview in the document if
you checked the box.
No... you're right. I just .... I don't know what I was thinking. :-)
Or your model could implement commit grouping itself. The dialog
controller would simply begin a group, the dialog would only ever
set property values in response to actions of the controls, and
when the dialog is closed, either commit or revert the group.
Again, such a "group" could very straightforwardly be contained by a
dictionary. There's no particular reason to use an Undo stack here,
as typically the user doesn't back out settings changes in a dialog
one by one, so the *order* of the changes doesn't need to be
preserved, just the fact that they have changed.
I'm not advocating an undo stack here. I'm simply saying keep track of
a group of changes. How you do it is up to you. (A dictionary is
clearly a good choice.)
If the controls in the dialog are directly bound to properties of
the model, you'd even save a bunch of code. Then each dialog
controller is nothing more than a nib with a bunch of controls
bound to a model, and essentially three lines of code to begin,
commit, or revert changes.
Well, it's certainly possible (even likely) that bindings changes
the picture considerably. However, for now I'm not using bindings
because learning the ins and outs of them is going to slow me down
and I'm on a ridiculous schedule as it is.
Which was my excuse as well. :-) If you're simply binding a control
to a value in a single object, (no array controller, or what not),
then it's ridiculously simple.
So for now I'm much faster doing things the old-fashioned way. I
have a bunch of utility methods in a category on NSMutableDictionary
that allows me to get/set most UI states with one line of code, so
at present every action has one line, and every "setter" to set the
initial UI state from the settings is one line.
With 50 settings, that's quite a bit of code. If it's really simply
setting values in a dictionary, it's truly as simple as selecting a
target from the popup, checking "bind", and typing the name of the
value in the dictionary. I'd really encourage you to take 15 minutes
to experiment with it.
--
Seth Willits
_______________________________________________
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