The UndoEngine abstract class provides a default implementation of undo functionality at design time. An undo unit represents a single unit of undoable work. This unit is added to a stack and the user can then walk the stack to undo each action. Undo units typically are designed to toggle, which means that calling undo twice returns the application to its starting state.

The UndoEngine class takes advantage of the following characteristics of objects running within the designer:

All interesting objects can be persisted to some format by the designer loader.

All objects raise property-change notifications when a property is changed.

IDesignerHost offers the idea of transactions, which can be used to fabricate an undo action that spans multiple smaller actions.

With these features, UndoEngine can fabricate any undo units it needs automatically.

Note:

Do not change property values directly. The UndoEngine class requires you to use the appropriate TypeDescriptor to change property values.

UndoEngine monitors for change notifications to create undo units, and the units themselves consist of serialized object states. The following table shows the services that must be available when UndoEngine is created.

Because the UndoEngine class requires ComponentSerializationService and IComponentChangeService, it is available only at design time.

The undo engine tracks transactions and creates a single undo unit that encompasses a transaction. As a result, the undo engine has control over the duration of an undoable action. Also, because transactions can be named, undoable actions inherit their names from the current transaction. If no transaction is available and a change is reported, the undo engine creates an undo name based on the type of change (for example, "Change property 'Text'").