More Undo/Redo docs on the way? | Infragistics Forums

WayneMiller said:

Regarding the UndoExecuteContext, what is the difference between "ExecuteItemType" and "Reason"? They look very similar to me.

The Reason is the actual type of operation being performed which currently can be Undo, Redo or Rollback where Rollback is a cancellation of a started open transaction (e.g. if an exception happens while the transaction is in progress). The ExecuteItemType is essentially the resolved action that is happening so if the Reason is Undo then you would get Undo, if the Reason is Redo you would get Redo but if the Reason is Rollback you would get Undo or Redo depending on whether this is rolling back a transaction occurring as part of an undo or redo.

WayneMiller said:

Why is Target a required member of UndoUnit? How is it used by UndoManager?

In theory Target did not absolutely have to be required but it would be too easy to overlook. The Target is there primarily to allow generic identification of operations that affect a given object. So for example if you were creating an edit application that might be the document being manipulated. If the user then went and closed the document, you would probably want to go through the history and remove any actions targetting that document because they can no longer be undone/redone. So you would use the RemoveAll method and look for units targetting that document. The UndoManager itself doesn't make use of that.

WayneMiller said:

Is this implementation essentially how I would use UndoManager, or would I use it in a different way?

One important thing to realize is that UndoUnits are not automatically moved from the Undo history to the Redo history (or vice versa). The rationale being that if the action that the unit would take would cause something to be added to the undomanager then you would end up having the unit being executed and the unit added as a result of the action added to the history or the undomanager would have to make general (and error prone) assumptions such as ignoring requests to add units to the history while an undo/redo is in progress. So if you have a case where the undounit when executed will be doing something that does not result in an undounit being added to the UndoManager then you might have the UndoUnit add itself to the UndoManager within the Execute method. So something like:

executeInfo.UndoManager.AddChange(this);

As to how to use the UndoManager there is no single description I can give. We have a number of helper methods to try and deal with common undo scenarios like modifying a collection (excluding reset such as clear) or modifying the value of a property. These methods then manipulate the collection/property when executed and it is assumed that it was those property/collection changes that generated the original property change that caused the original undounit to be created and that the change resulting from the Execute will do so as well (since the undo unit would have had to have access to the state of the object prior to the change - i.e. the old and new state).

There are overloads of AddChange which take a Func or Action for both undo and redo. These assume that the action/func will not result in an undounit being automatically added and it will add itself back into the history as described above.