org.browsecode.helpers.undo
Interface UndoableEdit2
- All Superinterfaces:
- javax.swing.undo.UndoableEdit
- All Known Subinterfaces:
- DataBitUndoableEdit<T>
- All Known Implementing Classes:
- CompoundUndoableEdit2, DataBitCompoundUndoableEdit
public interface UndoableEdit2
- extends javax.swing.undo.UndoableEdit
Simialar to UndoableEdit, but more powerful. Edits may be done out of order.
canUndo() and canRedo() return check whether or not the data is in a state that the undo/redo can be applied, even though all actions that happened after this may or may not have been undone.
Field Summary |
static boolean |
debug
|
Methods inherited from interface javax.swing.undo.UndoableEdit |
addEdit, canRedo, canUndo, die, getPresentationName, getRedoPresentationName, getUndoPresentationName, isSignificant, redo, replaceEdit, undo |
debug
static final boolean debug
- See Also:
- Constant Field Values
getKeyObject
java.lang.Object getKeyObject()
- Returns the key object that was changed.
This may be used to do a search for what other changes this change is dependent on -- so, for example, if you edit a chunk of text twice, both Deltas should return the same data storage thing which has that information. Then you can tell the user that all these things need to be undone to undo this thing alone.
- Returns:
getChangeType
java.lang.Object getChangeType()
canMergeWith
boolean canMergeWith(UndoableEdit2 undoableEdit)
- Whether or not this can merge with another thing. For example, you always need both of these to be true (and usually the UndoHandler will check these first)
a) the keyObject's need to be identical
b) the change types need to be identical
c) The merges need to be consecutive or connected in some way.
For example, a text editor would say yes to inserts if the inserts of each letter were consecutive, and would say no if the
- Parameters:
undoableEdit
-