GoJS API
/ to search
    Preparing search index...

    Class UndoManager

    An UndoManager observes and records model and diagram changes in transactions and supports undo/redo operations. If you want your users to be able to perform undo and redo, you will need to first set the isEnabled property to true.

    Typically an operation will call startTransaction, make some changes to the Model and/or Diagram, and then call commitTransaction. Any ChangedEvents that occur will be recorded in a Transaction object. If for some reason you do not wish to complete the transaction successfully, you can call rollbackTransaction instead of commitTransaction.

    For convenience the Diagram.commit and Model.commit methods execute a function within a transaction and then perform a commit, or else a rollback upon an error.

    The history property is a list of Transactions. commitTransaction will add the currentTransaction to the history list. rollbackTransaction will undo the changes remembered in the currentTransaction and then discard it, without changing the history. You can limit how many transactions are remembered in the history by setting maxHistoryLength.

    Transactions may be nested. Be sure to call either commitTransaction or rollbackTransaction for each call to startTransaction. We recommend that you call Model.commit or Diagram.commit to avoid possible situations where calls to start and commit/rollback are not paired and properly nested.

    Avoid repeated programmatic start-commit-start-commit calls as a result of a user's actions, because that will be confusing to the user. Instead, start, make all changes, and then commit.

    If you want to restore the diagram to the state before the latest complete transaction, call undo. Call redo to change the diagram to a later state. If after some number of undo's you start a transaction, all of the history after the current state is discarded, and a new transaction may be recorded. You cannot undo or redo during a transaction, although you can rollback a nested transaction.

    Initially each Model has its own UndoManager. UndoManagers may be shared by multiple Models by replacing the standard Model.undoManager created by the model constructor.

    There are several informational properties:

    A transaction may not be ongoing when replacing a Diagram.model, because it would not make sense to be replacing the UndoManager (the Model.undoManager) while changes are being recorded.

    Replacing a Diagram.model copies certain properties from the old UndoManager to the new one, including isEnabled and maxHistoryLength.

    Index

    Constructors

    • The constructor produces an empty UndoManager with no transaction history. It is unusual to call this -- an UndoManager is automatically constructed for a Model by the Model constructor.

      Parameters

      Returns UndoManager

    Accessors

    • get currentTransaction(): Transaction | null

      This read-only property returns the current Transaction for recording additional model change events. This is initialized and augmented by handleChanged before it is added to history by a top-level call to commitTransaction. The value will be null between transactions, and may be null during a transaction before any recorded changes occur.

      Returns Transaction | null

    • get history(): List<Transaction>

      This read-only property returns the whole history, a list of all of the Transactions, each representing a transaction with some number of ChangedEvents. The first Transaction is the oldest.

      You should not modify this List.

      Returns List<Transaction>

    • get historyIndex(): number

      This read-only property returns the index into history for the current undoable Transaction. The value is -1 if there is no undoable Transaction to be undone. The initial value is -1, when no transactions have been committed.

      Returns number

    • get isEnabled(): boolean

      Gets or sets whether this UndoManager records any changes. The default value is false -- you need to set this to true if you want the user to be able to undo or redo.

      You can temporarily turn off recording by setting Diagram.skipsUndoManager and Model.skipsUndoManager to true.

      Returns boolean

    • get isUndoingRedoing(): boolean

      This read-only property is true during a call to undo or redo.

      Returns boolean

    • get maxHistoryLength(): number

      Gets or sets the maximum number of transactions that this undo manager will remember. When a transaction is committed and the number exceeds this value, the UndoManager will discard the oldest transaction(s) in order to meet this limit. The initial value is 999. Any new value must be an integer. A negative value is treated as if there were no limit. A zero value will not remember any Transactions in the history, but will allow commits and rollbacks to occur normally, including raising "Transaction" type ChangedEvents.

      This property is useful in helping limit the memory consumption of typical applications. But this does not limit the number of ChangedEvents that are recorded, because there may be an unlimited number of those within each Transaction. Decreasing this value will not necessarily remove any existing Transactions if there currently exist more in history than the new value permits.

      Returns number

    • get nestedTransactionNames(): List<string>

      This read-only property returns a stack of ongoing transaction names. The outermost transaction name will be the first item in the list. The last one will be the name of the most recent (nested) call to startTransaction.

      You should not modify this List.

      Returns List<string>

    • get transactionLevel(): number

      This read-only property returns the current transaction level. The value is zero when there is no ongoing transaction. The initial value is zero. startTransaction will increment this value; commitTransaction or rollbackTransaction will decrement it. When this value is greater than zero, canUndo and canRedo will be false, because a transaction is ongoing and additional logically related model change events may occur.

      Returns number

    Methods

    • Make sure this UndoManager knows about a Model for which it may receive ChangedEvents when the given Model is changed. The model will also receive notifications about transactions and undo or redo operations.

      You should not call this method during a transaction.

      Parameters

      • model: Model

        A Model that this UndoManager will managing.

      Returns void

    • This predicate returns true if you can call redo. This will return false if isEnabled is false (as it is by default), if any transaction is ongoing, or if there is no transactionToRedo that can be redone.

      Returns boolean

      true if ready for redo to be called.

    • This predicate returns true if you can call undo. This will return false if isEnabled is false (as it is by default), if any transaction is ongoing, or if there is no transactionToUndo that can be undone.

      Returns boolean

      true if ready for undo to be called.

    • Clear all of the Transactions and clear all other state, including any ongoing transaction without rolling back. However, this maintains its references to its Models.

      You should not call this method during a transaction.

      Returns void

    • Inform this UndoManager that it will no longer be receiving ChangedEvents when the given Model is changed. The model will no longer receive notifications about transactions and undo or redo operations.

      You should not call this method during a transaction. If you call this method between transactions when there is a transaction history, you should be careful that there are no ChangedEvents referring to that model in any Transactions.

      Parameters

      • model: Model

        A Model that this UndoManager should no longer manage.

      Returns void