Undo vs NSArrayController
Undo vs NSArrayController
- Subject: Undo vs NSArrayController
- From: Quincey Morris <email@hidden>
- Date: Fri, 22 Feb 2008 16:28:10 -0800
This has probably been discussed on the list before, but I'm having
trouble working out at what moment to intervene to set the name of an
undo action, when a property change is triggered by a
NSArrayController via bindings.
Suppose there's a (non-core-data) document with a "NSArray* persons"
property whose contents are objects of class Person, which in turn has
a 'personName' property. Suppose there's a nib file having the
document as file's owner, containing a NSArrayController bound to the
'persons' property. Let's say there's a window in there containing a
NSTableView (which allows multiple selections) bound to the
NSArrayController, and a text field bound to the NSArrayController's
selection. Let's say that Person's 'personName' setter might have KVO-
compliant side effects on other properties, and that there might be
other sources of changes to 'personName' (such as menu items).
This seems to me to be a very basic, very straightforward setup.
Now imagine the user selects one or more rows in the table, and edits
the 'personName' via the text field. Assume that there's already a
mechanism in place to capture the changes for the undo action itself.
Where do I go to set the undo action name so that the menu item says
"Undo Name Change" (and, for bonus points, "Undo Name Changes" when
multiple rows were selected)? I can't do it in the data model, because
there'll be multiple changes for multiple properties. I can't do it by
overriding setValue:forKeyPath or any other part of the observing
mechanism, for the same reason. I can't do it by subclassing
NSArrayController, because there's nothing in it to override at the
appropriate moment.
The only place I can think of to intervene would be the individual
user interface elements (the text field, in this case). But I don't
want that to be the answer because it means inventing a strategy for
every possible UI element (other properties might use something other
than text fields), and it means hard coding knowledge every UI element
in the document class (or whatever ends up functioning as the
controller), and I'm not sure it's even possible for all kinds of UI
elements.
Am I missing something blindingly obvious here, or is this just plain
difficult?
_______________________________________________
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