2008 06 22Inspecting NSUndoManager's undo stack
NSUndoManagerand its retain policy so I wrote some code, and then I was enlightened :) There's a great article on ex-cinder.com that explains the concepts, so I won't go into detail - check the code out.
Two methods and their retain behaviours
When doing an undoable action, you register in
NSUndoManager a method than undoes what you just did. It will be called when undoing. Depending on your method's arguments, call one of these :
registerUndoWithTargetregisters a call with one ObjC object as parameter
prepareWithInvocationTargetregisters a call with multiple parameters, even non ObjC objects like
If you set a value from 4 to 5, register in the undomanager a call to set the value to 4, then set it to 5. If you add an object with
addObject:, register a call to
removeObject:. That's really all there is to it.
registerUndoWithTarget both retain their arguments. Each undoable change ups the retain count. So when moving an object around, the retain count will go up at each position change. Don't worry if an object reaches a retain count of 30. Clearing the undo stack gets the retain count back to its initial value.
Peering through NSUndoManager
NSUndoManager does not offer any public way to view its undo and redo stacks. Thanks to F-Script, we can see that it has an undocumented
_undoStack method, but nothing for the redo stack.
NSUndoManager's header file shows 2 instance variables
_undoStack. We'll fetch these with
object_getInstanceVariable and call
description on them, which dumps their contents.
Undoing adding and removing of objects in an NSArray
Storing objects in an array ups their retain count. Create an object (count=1), add it in an array (count=2). If you don't release the object (count=1) after adding it to the array,
NSUndoManager will restore the object to its original retain count (1) when disposing of it, thus it will never be released. This is fine if you overload your objects' release method and plan on pooling them. If not, release your objects after adding them to the array or they will stick around forever.
Sample codeUndo Inspector.zip
Just tried NSUndoManager's valueForKey:@"_undoStack" and it works like a charm. Great tip, merci bien !
An alternate (quick and easy) way of accessing private ivars is to use KVC, in particular -valueForKey: and -setValue:forKey: . Although some classes may trap this, most don't and it's a very useful technique that I use often (actually I used it too while in gdb console to inspect NSUndoManager stacks).