On Jan 29, 2014, at 11:07 AM, Keary Suska <cocoa-...@esoteritech.com> wrote:

> As the object of an action the "deleted" object should be retained by 
> NSUndoManager, so you don't have to track it yourself.

*light bulb*
For whatever reason, I had it in my head that neither the target of the undo 
action nor the parameter(s) were retained — but now that I read the docs more 
carefully, I see that the parameter to the action (“object” in the 
documentation) is retained, in both the simple 
(registerUndoWithTarget:selector:object:) and invocation-based 
(prepareWithInvocationTarget:) cases.

This also answers another question I was going to ask:

if I were manually holding onto model objects which had been removed as part of 
some undoable/redoable action, it occurred to me that any object which got 
removed as part of an undo (e.g. undoing an “add”) would need to be held onto 
in case of a redo. But, if the user performed some other undoable action 
instead, then the redo stack will be cleared and any objects I was holding onto 
(in case they needed to be re-added as part of a redo) would no longer be 
needed. Thus, I would need some way of being notified when the redo stack gets 
cleared so that I could release any such objects.

But if the NSUndoManager is the one retaining those objects, then presumably 
the objects will get released automatically when the redo stack gets cleared. 
Plus, any additional actions which target those objects would have to also be 
on the redo stack, below the “redo add object” action, and so those actions 
will also get removed when the redo stack is cleared and there’s no concern of 
any lingering actions whose target is the now-deallocated object.

> For completeness I would add that I find it best that each root object in 
> your data hierarchy have its own undo manager that it disposes of when the 
> object deallocates. This is, for instance, how the document architecture 
> handles it.

My app is document-based and I am indeed using the undo manager for each 
document in exactly this way.

Many thanks for the pointers!

Matt
_______________________________________________

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to