I'm still really struggling with the documentation for Undo/Redo. Will there be more documentation posted soon?
Hello Wayne,
Thank you for your post. I have been reading through it and since the Undo/Redo Framework has been released with version 12.1, the documentation for the framework has also been released. You can find detailed information regarding the Undo/Redo Framework in our online documentation here: http://help.infragistics.com/Help/NetAdvantage/WPF/2012.1/CLR4.0/html/Infragistics_Undo_Redo_Framework.html
Please let me know if you need any further assistance on the matter.
Sincerely,
Krasimir
Developer Support Engineer
Infragistics
www.infragistics.com/support
I am just checking if you require any further assistance on the matter.
The documentation online is a fine start, but I was hoping for much more documentation than what exists there already.
I sort of understand what is going on with Undo units, but I don't understand what registration is and why its needed. Is it always used, or just in special cases?
Code snippets in the documentation would be very useful. I know that there are larger sample projects that can be downloaded, but these are not as effective in learning the simple concepts. Here is an example of Microsoft documentation that illustrates the use of a small, complete example inline with the document:
http://msdn.microsoft.com/en-us/library/system.componentmodel.composition.hosting.compositioncontainer
WayneMiller said: I sort of understand what is going on with Undo units, but I don't understand what registration is and why its needed. Is it always used, or just in special cases?
When AddChange(UndoUnit) is called, the UndoManager determines where to to place the unit. If an Undo is in progress then it is added to the Redo stack on the assumption the change is happening as a result of the undo in progress. If an Undo is not in progress (so either nothing is being executed in the UndoManager or a Redo is in progress) then the unit is added to the Undo history. If a Redo is not in progress then the redo history will be cleared as happens in typical undo functionality.
Andrew Smith"] One important thing to realize is that UndoUnits are not automatically moved from the Undo history to the Redo history (or vice versa).
One important thing to realize is that UndoUnits are not automatically moved from the Undo history to the Redo history (or vice versa).
How do I indicate that I want to add something to the Redo Stack?
Does AddChange(UndoUnit) imply that I'm adding to the Undo Stack and calling Execute on the change, or could it be somehow that this same method also adds to the redo stack (you seem to imply this in your example)?
WayneMiller said: I do not see any documentation for the method, "Execute"
I do not see any documentation for the method, "Execute"
I'll forward this one along. I'm not sure why the protected members aren't included in the help.
WayneMiller said: Regarding the UndoExecuteContext, what is the difference between "ExecuteItemType" and "Reason"? They look very similar to me.
Regarding the UndoExecuteContext, what is the difference between "ExecuteItemType" and "Reason"? They look very similar to me.
WayneMiller said: Why is Target a required member of UndoUnit? How is it used by UndoManager?
Why is Target a required member of UndoUnit? How is it used by UndoManager?
WayneMiller said: Is this implementation essentially how I would use UndoManager, or would I use it in a different way?
Is this implementation essentially how I would use UndoManager, or would I use it in a different way?
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.