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.
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?
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?
Thanks for the responses. I am very excited about Undo/Redo and would like to use it. Here is an example of the difficulty I'm having with the documentation:
http://help.infragistics.com/Help/NetAdvantage/WPF/2012.1/CLR4.0/html/InfragisticsWPF4.Undo.v12.1~Infragistics.Undo.UndoUnit_members.html
I do not see any documentation for the method, "Execute"
Regarding the UndoExecuteContext, what is the difference between "ExecuteItemType" and "Reason"? They look very similar to me.
Why is Target a required member of UndoUnit? How is it used by UndoManager?
Is this implementation essentially how I would use UndoManager, or would I use it in a different way?
using Infragistics.Undo;
namespace UndoExample
{
public class Change : UndoUnit
public string MyProperty { get; set; }
public Change()
MyProperty = "Original.";
}
protected override bool Execute(UndoExecuteContext executeInfo)
if (executeInfo.ExecuteItemType == UndoHistoryItemType.Undo)
MyProperty = "Undone.";
else
MyProperty = "Redone.";
return true;
public override string GetDescription(UndoHistoryItemType itemType, bool detailed)
return "Change MyProperty";
public override object Target
get { return null; }
class Program
static void Main(string[] args)
UndoManager mgr = new UndoManager();
var change = new Change();
System.Console.Out.WriteLine(change.MyProperty);
mgr.AddChange(change);
mgr.Undo();
WayneMiller said: 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?
WayneMiller said: 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.
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)?
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.