UndoCommands

Remarks

⚠ Undo is the manager's verb and not the text field's, which is why this is here and not in TextField. IUndoManager already argues that a control must not own a stack because undo has to interleave with everything else an application does; registering edit.undo on the control would have contradicted that at the other end — CommandRoute.Resolve stops at the first element that registered the id and a refusal from it is final, so a focused field answering edit.undo would swallow the application's Undo for as long as the caret was in it, whatever its canExecute said. Installed where the manager is, the same walk gives the answer the field wanted: ⌘Z in a text box climbs out of the field and reaches the manager the field recorded into.

Nearest wins, on DocumentCommands's terms. A panel that owns a document's stack sets UndoManager and calls Install on the same element; the route then picks that panel's Undo while the focus is inside it and the application's everywhere else, with neither knowing the other exists.

⚠ The manager is looked up on every ask rather than captured, for FindUndoManager's reason: an application is entitled to replace UndoManager after the install, and a captured one would be the stack that happened to be there when the window opened. Finding nothing greys both items rather than making them run and do nothing.

Fields and properties (2)

• public const string Undo

  Take back the last edit on the nearest undo manager.

• public const string Redo

  Put back the last edit taken back.

Methods (1)

• public static void Install(UiElement element)

  Makes an element answer Undo and Redo for the nearest manager.

Used by (2)

• UiApplicationVixen.Ui.Desktop
• UndoCommandsTestsVixen.Ui.Tests