Name: jk109818 Date: 02/24/2003


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)


FULL OPERATING SYSTEM VERSION : Windows 2000, SP 3


ADDITIONAL OPERATING SYSTEMS : Solaris, Linux, ...



A DESCRIPTION OF THE PROBLEM :
The AbstractUndoableEdit class in javax.swing.undo maintains the
done/undone state of subclasses using this class. It currently only
allows the creating of such an Edit in the "done" state, that is, one
can only call undo() on it.

An executor of Edits can therefore not call redo() on this edit and
has to implement the actual functionality twice, once in redo() and
once for the first time execution.

An additional constructor would allow the implementor of an Edit to
create a not-already-done Edit, which could subsequently be
redone (redo()) for the first time by the executor.

Example
------------
public class ScaleEdit extends AbstractUndoableEdit {

private double s;
private JPanel p;

public ScaleEdit(double x, JPanel p) {
   this.s = x;
   this.p = p;
}

public void redo() throws CannotRedoException {
    super.redo();
    p.scale(s)
}

public void undo() throws CannotUndoException {
   super.undo();
   p.scale(1/s);
}
} // class ScaleEdit

public class MyPanel extends JPanel {

public void postEdit(UndoableEdit edit) {
   undoableEditSupport.postEdit(edit);
   edit.redo();
}

} // class MyPanel

REMARK: the redo() in postEdit will throw an
CannotRedoException because the ScaleEdit is in the state
"hasBeenDone".



REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
2 Workarounds:

1. Create a do() method, called for the first time and called by
redo()
2. Create a DoableEdit which re-implements the state machine of
AbstractUndoableEdit. (this has an impact on the other classes
that derive from AbstractUndoableEdit: CompoundEdit and
UndoManager.
(Review ID: 181683)
======================================================================