Taking a change back over the top of writes that are not yet recorded produces a library state
no undo step describes, so UndoManager#suspendUndo opens one of these for as long as that
window is open, and the undo UI declines meanwhile. It is not a lock: two commands may write
to one library at the same time, and undo returns once the last of them has handed over.
Closing is idempotent and may happen on any thread, so a task that can finish through more than one path — success, failure, cancellation — may close on all of them.
| Modifier and Type | Field and Description |
|---|---|
| public static final UndoSuspension | NONE
Held by work that is already inside another suspension, where ending one early would reopen the window. |
| Modifier and Type | Method and Description |
|---|---|
| public void |
| NONE | back to summary |
|---|---|
| public static final UndoSuspension NONE Held by work that is already inside another suspension, where ending one early would reopen the window. Closing it does nothing. | |
| close | back to summary |
|---|---|
| public void close() Redeclares java. Ends the suspension. Never throws, so it is safe in a
| |
