Re: Preserving undo actions on deleted targets
Re: Preserving undo actions on deleted targets
- Subject: Re: Preserving undo actions on deleted targets
- From: Michael Starke <email@hidden>
- Date: Wed, 29 Jan 2014 17:03:24 +0100
As far as I know (and I use this in my application) if you use the
NSUndoManager prepareWithInvocationTarget:
the proxy that wraps the NSInvocation retains the target. Thus using a
[[undoManager prepareWithInovationTarget:myObject] remove] call should
ensure the object lives as long as the undo stack is valid. Works for
me. If not, I might have a bug there lingering too :)
-Michael
On 29.01.2014 16:30, Matthew LeRoy wrote:
I’m wondering if someone can provide some guidance or best practices on how I might preserve actions on the undo/redo stack when the target of those actions is deleted?
For example, say I have an application that allows me to add and remove records to and from a list — employee records, items in an inventory control system, anything really. I have model objects which represents each record, and those model objects register undo actions whenever their attributes/properties are changed. (I’m fairly certain this is the recommended best practice.)
I also want to be able to delete records, and to be able to undo that deletion. The Undo Architecture documentation clearly warns not to leave actions on the undo stack whose targets have been deallocated, and points to removeAllActionsWithTarget:. OK, so when I delete a record and thus delete the corresponding model object, I just call removeAllActionsWithTarget:modelObject — easy. But then I realize that now any undo actions that targeted that object are gone, and even if I undo the deletion I can’t keep undo-ing any changes which were made to that object prior to it being deleted (e.g. undo changing the name of an employee, changing the unit cost of an inventory item, etc).
I *think* the right approach here is to not delete/dealloc the model objects when their corresponding records are removed/deleted, but instead just remove the objects from the collection of “live” objects and hold onto them somewhere else for the purposes of re-inserting them in the collection if the deletion is undone. I suppose my model code for deleting a record from the live collection should register an undo action which calls “undelete” or “insert”; and the code for “undelete” or “insert” (and probably “add” as well) should register an undo action which calls “delete”?
I also shouldn’t call removeAllActionsWithTarget:modelObject, because there’s no way to re-insert those actions back into the undo stack if the deletion is undone and the model object is re-inserted back into the “live” collection. Instead, I just have to trust that the only way for the undo actions which target the “deleted” model object to get sent is for the undo action which undeletes the object to be sent first (because it is higher on the undo stack), thus putting the object back into the live collection. I don’t need to worry about undo actions getting sent to deallocated objects, because the objects aren’t getting deallocated.
Am I on the right track, or is there some other recommended pattern here?
Matt
_______________________________________________
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
--
___m i c h a e l s t a r k e____
geschäftsführer
HicknHack Software GmbH
www.hicknhack-software.com
___k o n t a k t____
+49 (170) 3686136
email@hidden
___H i c k n H a c k S o f t w a r e G m b H____
geschäftsführer - maik lathan | andreas reischuck | michael starke
bayreuther straße 32
01187 dresden
amtsgericht dresden HRB 30351
sitz - dresden
_______________________________________________
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