On Oct 6, 2011, at 07:40 , Keary Suska wrote: > AFAIK you will need to manage selection restoration semantics yourself, and > it may not be easy and it may be fragile. Note also that the preserve and > avoid empty selection settings will also have an effect. That being said, the > approach would be--before adding/deleting outside the controller--to grab the > managed object context's undo manager, open an undo group, add selection > restoration operations, perform the operation, then close the group. This > should cause the undo to restore selection. Of course, this is theory, as I > haven't had to actually do it, and more experienced Core Data wranglers may > have more to add.
I think your approach is basically correct. I can't remember if I ever needed to do this in a Core Data app, so I'm speaking a bit theoretically too. On Oct 6, 2011, at 1:14 AM, Richard Somers wrote: > Take for example a NSArrayController with a managed object context for the > content. If one or more objects are added to managed object context as the > result of an undo, the controller's selection does not change or update. > > Is there an easy way to set the controller's selection when an undo operation > adds objects back into a managed object context? The most important thing to keep in mind here is that the array controller is a distraction, and not any part of the problem. Bind the array controller's "selectionIndexes" binding to a NSIndexSet property in your data model, and the array controller's selection behavior essentially becomes a proxy for the data model property -- provided that any changes you make directly to the property are done KVO-compliantly. By moving the selection into the data model (so to speak), you remove the array controller from the problem, and that's a good thing. By "data model" I don't necessarily mean "Core Data model". I think it's perfectly fine to keep the selectionIndexes property as a custom non-Core-Data property of some object (for example, your NSPersistentDocument subclass or your document window controller subclass, if that's the kind of app we're talking about). You would have to modify every the action method of *every* undoable action to create an undo action [sorry, that's 3 semantically different uses of "action" in one sentence, but blame Cocoa, not me] that captures the selectionIndexes property value, if the action changes the selection. I don't think you need to create any explicit undo groups. The event-level implicit group is probably all you need. I also don't think this is fragile, though it may be. Because Core Data defers some processing (such as delete rule propagation) until it "needs" to do it, you may find the sequence of activities being more or less re-ordered, and that *might* mean trouble when you come to apply the undo actions. So, as Keary says, "it may not be easy and it may be fragile". However, there is a possible alternative that should be easy and non-fragile, if feasible. You should be able to put the selectionIndexes property into your Core Data model, though you might need to introduce an object of a new entity type into your Core Data model to hold the property. (Note: you can make the property transient, so that although the object will get saved in the persistent store, the property value won't, and selection changes shouldn't "dirty" your model. Or you can intervene at save time to prevent the object being saved. Or you can really save the selection status in the persistent store, if that makes sense for your app.) Under these circumstances, I think you'll get your selection undone and redone for free, simply by binding the array controller to the relevant Core Data property. There might be a fatal flaw in my reasoning here, and there may still be some difficulty about when the selection change happens relative to the insertion/deletion, but this is the approach I'd try if I had to solve your problem. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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]
