2008 06 22Inspecting NSUndoManager's undo stack
NSUndoManager and 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 likeNSPoint
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.
prepareWithInvocationTarget and 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 _redoStack and _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 code
Undo Inspector.zipJust 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).