On Sep 10, 2008, at 10:49 PM, Graham Cox 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.
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.
In that case, then passing settings from your document to the dialog,
and then after the dialog closes grab the settings back into the
document to apply the changes, doesn't make sense to me. It makes more
sense to me for the dialog controller to be given a reference to the
model and that's it. So your document/window controller/whatever isn't
responsible for applying the changes, the dialog controller is.
From there, your dialog could:
- Make copies of the values of all the settings it can change, let the
user change the model values as much as they want, and then if the
click Cancel, simply apply the saved values, or if they hit Apply,
then just close the window.
- Keep an undo-like stack of changes and undo them as necessary if
they click Cancel.
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. 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.
It's taken me until to even quite understand what you're asking.
Hopefully this helps or triggers a thought. :-)
--
Seth Willits
_______________________________________________
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]
