On 28/04/2010, at 2:41 PM, Markus Spoettl wrote: > I'm not sure I follow entirely, I sounds like there's some information > missing that explains why the node deletion itself isn't an undoable > operation. Which appears to me is causing the problem.
The node deletion is undoable. So is node removal and node addition to the tree, which can occur when a node is moved (to another place in the same tree, or another tree). > If it was undoable, the node would never get deallocated it would just be > stored someplace else (UM). The target weak ref in the undo operations > recorded before the node deletion would still be valid, and that's what's > important. No? > > There are probably good reasons why the node removal isn't undoable and the > problem is legitimate, I just can't think of one right now. The node will not get deallocated if an undo task is referencing it as a parameter (as for deletion, removal), but it's not clear to me that there cannot be other undo tasks referencing it as a target later than a removal undo (something else can be retaining the node and mutating its properties for example, which could cause undo tasks to be submitted). I guess the problem is I can't easily visualise the state of the undo manager with respect to what it's retaining and what it's holding weak refs to as a function of time (and various states, such as some stuff on the redo stack). I'm getting that clouded, frustrated feeling when I think about it ;-) What's driving my question is that I seem to be occasionally getting crash reports indicating that an undo task is trying to access a deleted object but of course I never get any such problem when I'm working on my app or debugging myself. So I'm trying to make sure that my memory management is clean regardless of what byzantine pathways users happen to follow, and it strikes me that the best way to do that is to ensure all undo tasks targeting a node (weakly) are mopped up when the node is dealloced. On the face of it this shouldn't be easily possible - and isn't, when I'm driving - but crash reports indicate that such a state can be reached. The real picture is heavily complicated by the fact that plenty of places retain nodes for their own purposes; it's not just a conversation between the node, its parent and the undo manager. --Graham _______________________________________________ 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]
