On 28/04/2010, at 12:00 PM, Jens Alfke wrote: > > On Apr 27, 2010, at 6:55 PM, Graham Cox wrote: > >> Here's the problem: Any tasks on the undo stack that refer to a particular >> target must be removed when that target is dealloced. > > I don't know your app, but this sounds backwards to me. Don't tasks/nodes > need to be kept around for as long as an undo item refers to them? Otherwise, > what happens when the user tries to undo/redo that step? > > In other words, I would expect that an undo item would have strong references > to the tree nodes it affects. > > —Jens
If the node is a parameter to an undoable operation (removeNode, addNode, e.g.) then that's true, the undo task retains the node. If the node is a target for a task however, it is not retained. The UM does not retain its targets (this makes sense if you consider that a document owns its UM, and a document could well be the target of an undo task, as well as being in line with the usual rule that targets are not retained). In general the sequence of events keeps things in order - for example if a node is removed then an undo task exists to undo that removal which retains the node that was removed. Because the UM is retaining the node, other undo tasks that target it can still exist, so they can happily live in the undo stack with their weak refs and all is well. But eventually tasks might get removed from the undo stack, for example when its limit is reached such that old tasks are discarded. At that point, the remove task might get discarded, which releases the node, causing it to be dealloced. Other tasks still on the stack that target that node are now stale - they should have been removed by the dealloc of the node but were not. If you notice, NSDocument calls -removeAllActionsWithTarget:self on its UM in its -dealloc method. This seems to me to be the right thing to do and the right time to do it. But the same diligence needs to be applied to all objects that talk directly to the undo manager, which requires that such objects can find the UM at -dealloc time somehow. --Graham _______________________________________________ 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 arch...@mail-archive.com
