Re: NSUndoManager implementing Redo
Re: NSUndoManager implementing Redo
- Subject: Re: NSUndoManager implementing Redo
- From: Bill Cheeseman <email@hidden>
- Date: Fri, 12 Jul 2002 13:23:44 -0400
on 02-07-12 8:38 AM, petite_abeille at email@hidden wrote:
>
One way, or the other,
>
registerUndoWithTarget has only one selector as there is no technical
>
differences between undo/redo...
In each of two methods in an array object addition and deletion scenario,
the selector you register with the undo manager is the other method. In your
DELETE method, the selector you register is ADD; in your ADD method, the
selector you register is DELETE. Each method serves as the undo action for
the other method, and each method serves as its own redo action.
There is no rule in Cocoa that requires you to register the same method for
undo and redo, although that is convenient when undo and redo toggle a
simple data value back and forth between two states. When the action being
undone and redone is more complex, you often have to resort to calling a
pair of methods in alternation, one of which knows how to construct a state
and the other of which knows how to deconstruct it -- for example, insertion
and removal of objects in arrays. You could even chain multiple selectors to
one another in a multi-state ring structure, if you wanted to, although this
would depart from the "toggle" behavior underlying the undo/redo menu item
concept.
Most of the documentation and examples for implementing undo and redo use as
their model a simple, reversible data state, where a single method can serve
both as undo and redo action by passing alternating data states. For this
reason, many people start out thinking that registration of undo actions
*requires* that you register the same method each time, both for undo and
for redo. Many people even go so far as to understand the underlying
registration mechanism as somehow causing the method in which an undo action
is registered to be replayed over and over again, with alternating data
states being fed to the registration method each time. But it isn't so.
Registration of a selector as an undo action causes *that selector* (call it
selectorOne) to be called an Undo time. SelectorOne can be any method; it
need not be the method in which it is registered, although it often is. At
Undo time, the registered selectorOne will execute, and it will register
whatever method it specifies as its undo selector (call it selectorTwo). At
Redo time, the registered selectorTwo will execute, and it will register
whatever method it specifies as its undo selector (call it selectorThree).
And so on. Sometimes selectorOne, selectorTwo, and selectorThree are all the
same method. Sometimes selectorOne and selectorThree are the same method,
while selectorTwo (and selectorFour) are another method. And, theoretically
at least, all of them could be different methods, presumably with selectorN,
somewhere down the line, being the same method as selectorOne, in order to
close the circle and allow it to be repeated.
Another way of explaining this is that many people understand the
documentation to say that it is only the data state that can be varied when
an undo action is recorded. In fact, the selector can be varied instead (or
in addition).
>
On the other hand, if you are simply talking about adding object to an
>
array or something, why not simply follow this "convention"? Eg:
>
>
- (NSMutableArray) departements;
>
>
- (void) addToDepartements: (id) aValue
>
{
>
[NSUndoManager registerUndoWithTarget: self selector:
>
@removeFromDepartements object: aValue]
>
}
>
>
- (void) removeFromDepartements: (id) aValue
>
{
>
[NSUndoManager registerUndoWithTarget: self selector:
>
@addToDepartements object: aValue]
>
}
This is exactly my original point. Except that a one-time-only method is
required to instantiate the object aValue in the first place. You can't
register this initial instantiation method as a redo method, because once
you're into the undo/redo cycle the object aValue is already in existence
and saved on the undo or redo stack. You don't want to instantiate another
copy of it at Redo time.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.