Re: Cocoa undo considerations
Re: Cocoa undo considerations
- Subject: Re: Cocoa undo considerations
- From: Chris Meyer <email@hidden>
- Date: Wed, 11 Jul 2001 12:29:01 -0700
- It should be implemented at the model (from MVC) level. Right ?
Yes.
- NSUndoManager's -setActionName: should be invoked at the controller
level, as a single click in the GUI can make 10's of pushes on the undo
stack and having the last elementary action name would not make sense;
and only the controller knows what the GUI wants to do. Still OK ?
Yes, but make sure when you call setActionName you do so on the
model's undoManager, not on the controller's. When I did it on the
controller it didn't set the action name.
- Again regarding controllers : should those push an extra invocation
into the undo manager that tells which part of the GUI will need to
redisplay itself on undo ?
If your model is set up properly to inform the controller when it
changes, the controller should automatically take care of the
updating...
- Adding undo/redo to methods modifying objects is pretty
straightforward. But when a method removes (delete) an object, this
object should not be deallocated but instead stored in a "saved objects"
pool (ie, NSMutableArray), so that the invocations stored in the undo
manager stay valid. And that pool should be emptied when one wants to
get rid of the undo stack. Makes sense ?
You don't really need to worry about retaining it if its an argument
to the NSInvocation object returned by the
prepareWithInvocationTarget: of NSUndoManager. NSInvocation will
retain it as far as I understand.
- Are there other things to have in mind when implementing undo ?
See
http://cocoadev.com/index.pl?NSUndoManager and add any useful
info there please!