A new undo action will be added to the undo stack, with the title given as i_title. As long as the context is not left, every undo action added to the stack will be treated as sub action. This means it will not be directly accessible at the Undo manager, not appear in any user interface, and cannot be separately undone or re-done.

Each call to enterUndoContext must be paired by a call to leaveUndoContext, otherwise, the document's undo stack is left in an inconsistent state.

Undo contexts can be nested, i.e. it is legitimate to call enterUndoContext and enterHiddenUndoContext multiple times without calling leaveUndoContext inbetween.

A hidden undo action does not, in any visible way, contribute to the undo stack. This means that

• Calling undo when the top-element is a hidden undo action will transparently undo this action, and also undo the new top element of the stack.
• Calling redo when the top-element is a hidden action will transparently redo this action, and also redo the new top element of the stack.
• In any user interface presenting the current Undo or Redo actions to the user, a hidden action will not be listed.

A new undo action will be added to the undo stack. As long as the context is not left, every undo action added to the stack will be treated as sub action. This means it will not be directly accessible at the undo manager, not appear in any user interface, and cannot be separately undone or re-done.

Each call to enterHiddenUndoContext must be paired by a call to leaveUndoContext, otherwise, the document's undo stack is left in an inconsistent state.

Undo contexts can be nested, i.e. it is legitimate to call enterUndoContext and enterHiddenUndoContext multiple times without calling leaveUndoContext inbetween.

If no undo action has been added since the context has been opened, the context is not only left, but silently removed, and does not contribute to the undo stack at all. In this case, possible listeners will be notified via XUndoManagerListener::cancelledContext.

Otherwise, the undo context will be closed, and added to the Undo stack; the redo stack will be cleared, and listeners will be notified via XUndoManagerListener::leftContext resp. XUndoManagerListener::leftHiddenContext

The redo stack is cleared when a new action is pushed onto the undo stack.

The Undo manager takes ownership of any actions pushed onto the undo stack. This means that if the action is finally removed from the Undo manager's control (e.g. by calling clear resp. clearRedo), it will be disposed, as long as it supports the XComponent interface.

If the Undo manager is locked at the moment the method is called, the call will be ignored, and the undo action will immediately be disposed, if applicable.

Effectively, invoking this method will

• invoke XUndoAction::undo on the top-most action of the undo stack
• move this undo action from the undo stack to the redo stack

Effectively, invoking this method will

• invoke XUndoAction::redo on the top-most action of the redo stack
• move this action from the redo stack to the undo stack

All actions will be removed from both the Undo and the Redo stack. Actions which implement the ::com::sun::star::lang::XComponent interface will be disposed.

All actions will be removed from the Redo stack. Actions which implement the ::com::sun::star::lang::XComponent interface will be disposed.

In particular, this method will

• remove all locks from the undo manager
• close all open undo contexts
• clear the undo stack
• clear the redo stack

Note that possible listeners will not get notifications for the single parts of the reset, i.e. there will be no single XUndoManagerListener::allActionsCleared, XUndoManagerListener::leftContext, etc., notifications. Instead, listeners will be notified of the reset by calling their XUndoManagerListener::resetAll method.