Liking cljdoc? Tell your friends :D

javax.swing.undo.AbstractUndoableEdit

An abstract implementation of UndoableEdit, implementing simple responses to all boolean methods in that interface.

An abstract implementation of UndoableEdit,
implementing simple responses to all boolean methods in
that interface.
raw docstring

javax.swing.undo.CannotRedoException

Thrown when an UndoableEdit is told to redo() and can't.

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeans™ has been added to the java.beans package. Please see XMLEncoder.

Thrown when an UndoableEdit is told to redo() and can't.

Warning:
Serialized objects of this class will not be compatible with
future Swing releases. The current serialization support is
appropriate for short term storage or RMI between applications running
the same version of Swing.  As of 1.4, support for long term storage
of all JavaBeans™
has been added to the java.beans package.
Please see XMLEncoder.
raw docstring

javax.swing.undo.CannotUndoException

Thrown when an UndoableEdit is told to undo() and can't.

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeans™ has been added to the java.beans package. Please see XMLEncoder.

Thrown when an UndoableEdit is told to undo() and can't.

Warning:
Serialized objects of this class will not be compatible with
future Swing releases. The current serialization support is
appropriate for short term storage or RMI between applications running
the same version of Swing.  As of 1.4, support for long term storage
of all JavaBeans™
has been added to the java.beans package.
Please see XMLEncoder.
raw docstring

javax.swing.undo.CompoundEdit

A concrete subclass of AbstractUndoableEdit, used to assemble little UndoableEdits into great big ones.

A concrete subclass of AbstractUndoableEdit, used to assemble little
UndoableEdits into great big ones.
raw docstring

javax.swing.undo.core

No vars found in this namespace.

javax.swing.undo.StateEdit

StateEdit is a general edit for objects that change state. Objects being edited must conform to the StateEditable interface.

This edit class works by asking an object to store it's state in Hashtables before and after editing occurs. Upon undo or redo the object is told to restore it's state from these Hashtables.

A state edit is used as follows:

 // Create the edit during the "before" state of the object
 StateEdit newEdit = new StateEdit(myObject);
 // Modify the object
 myObject.someStateModifyingMethod();
 // "end" the edit when you are done modifying the object
 newEdit.end();

Note that when a StateEdit ends, it removes redundant state from the Hashtables - A state Hashtable is not guaranteed to contain all keys/values placed into it when the state is stored!

StateEdit is a general edit for objects that change state.
Objects being edited must conform to the StateEditable interface.

This edit class works by asking an object to store it's state in
Hashtables before and after editing occurs.  Upon undo or redo the
object is told to restore it's state from these Hashtables.

A state edit is used as follows:


     // Create the edit during the "before" state of the object
     StateEdit newEdit = new StateEdit(myObject);
     // Modify the object
     myObject.someStateModifyingMethod();
     // "end" the edit when you are done modifying the object
     newEdit.end();

Note that when a StateEdit ends, it removes redundant state from
the Hashtables - A state Hashtable is not guaranteed to contain all
keys/values placed into it when the state is stored!
raw docstring

javax.swing.undo.StateEditable

StateEditable defines the interface for objects that can have their state undone/redone by a StateEdit.

StateEditable defines the interface for objects that can have
their state undone/redone by a StateEdit.
raw docstring

javax.swing.undo.UndoableEdit

An UndoableEdit represents an edit. The edit may be undone, or if already undone the edit may be redone.

UndoableEdit is designed to be used with the UndoManager. As UndoableEdits are generated by an UndoableEditListener they are typically added to the UndoManager. When an UndoableEdit is added to an UndoManager the following occurs (assuming end has not been called on the UndoManager):

If the UndoManager contains edits it will call addEdit on the current edit passing in the new edit as the argument. If addEdit returns true the new edit is assumed to have been incorporated into the current edit and the new edit will not be added to the list of current edits. Edits can use addEdit as a way for smaller edits to be incorporated into a larger edit and treated as a single edit. If addEdit returns false replaceEdit is called on the new edit with the current edit passed in as the argument. This is the inverse of addEdit — if the new edit returns true from replaceEdit, the new edit replaces the current edit.

The UndoManager makes use of isSignificant to determine how many edits should be undone or redone. The UndoManager will undo or redo all insignificant edits (isSignificant returns false) between the current edit and the last or next significant edit. addEdit and replaceEdit can be used to treat multiple edits as a single edit, returning false from isSignificant allows for treating can be used to have many smaller edits undone or redone at once. Similar functionality can also be done using the addEdit method.

An UndoableEdit represents an edit.  The edit may
be undone, or if already undone the edit may be redone.

UndoableEdit is designed to be used with the
UndoManager.  As UndoableEdits are generated
by an UndoableEditListener they are typically added to
the UndoManager.  When an UndoableEdit
is added to an UndoManager the following occurs (assuming
end has not been called on the UndoManager):

If the UndoManager contains edits it will call
    addEdit on the current edit passing in the new edit
    as the argument.  If addEdit returns true the
    new edit is assumed to have been incorporated into the current edit and
    the new edit will not be added to the list of current edits.
    Edits can use addEdit as a way for smaller edits to
    be incorporated into a larger edit and treated as a single edit.
If addEdit returns false replaceEdit
    is called on the new edit with the current edit passed in as the
    argument. This is the inverse of addEdit —
    if the new edit returns true from replaceEdit, the new
    edit replaces the current edit.

The UndoManager makes use of
isSignificant to determine how many edits should be
undone or redone.  The UndoManager will undo or redo
all insignificant edits (isSignificant returns false)
between the current edit and the last or
next significant edit.   addEdit and
replaceEdit can be used to treat multiple edits as
a single edit, returning false from isSignificant
allows for treating can be used to
have many smaller edits undone or redone at once.  Similar functionality
can also be done using the addEdit method.
raw docstring

javax.swing.undo.UndoManager

UndoManager manages a list of UndoableEdits, providing a way to undo or redo the appropriate edits. There are two ways to add edits to an UndoManager. Add the edit directly using the addEdit method, or add the UndoManager to a bean that supports UndoableEditListener. The following examples creates an UndoManager and adds it as an UndoableEditListener to a JTextField:

UndoManager undoManager = new UndoManager(); JTextField tf = ...; tf.getDocument().addUndoableEditListener(undoManager);

UndoManager maintains an ordered list of edits and the index of the next edit in that list. The index of the next edit is either the size of the current list of edits, or if undo has been invoked it corresponds to the index of the last significant edit that was undone. When undo is invoked all edits from the index of the next edit to the last significant edit are undone, in reverse order. For example, consider an UndoManager consisting of the following edits: A b c D. Edits with a upper-case letter in bold are significant, those in lower-case and italicized are insignificant.

Figure 1

As shown in figure 1, if D was just added, the index of the next edit will be 4. Invoking undo results in invoking undo on D and setting the index of the next edit to 3 (edit c), as shown in the following figure.

Figure 2

The last significant edit is A, so that invoking undo again invokes undo on c, b, and A, in that order, setting the index of the next edit to 0, as shown in the following figure.

Figure 3

Invoking redo results in invoking redo on all edits between the index of the next edit and the next significant edit (or the end of the list). Continuing with the previous example if redo were invoked, redo would in turn be invoked on A, b and c. In addition the index of the next edit is set to 3 (as shown in figure 2).

Adding an edit to an UndoManager results in removing all edits from the index of the next edit to the end of the list. Continuing with the previous example, if a new edit, e, is added the edit D is removed from the list (after having die invoked on it). If c is not incorporated by the next edit (c.addEdit(e) returns true), or replaced by it (e.replaceEdit(c) returns true), the new edit is added after c, as shown in the following figure.

Figure 4

Once end has been invoked on an UndoManager the superclass behavior is used for all UndoableEdit methods. Refer to CompoundEdit for more details on its behavior.

Unlike the rest of Swing, this class is thread safe.

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeans™ has been added to the java.beans package. Please see XMLEncoder.

UndoManager manages a list of UndoableEdits,
providing a way to undo or redo the appropriate edits.  There are
two ways to add edits to an UndoManager.  Add the edit
directly using the addEdit method, or add the
UndoManager to a bean that supports
UndoableEditListener.  The following examples creates
an UndoManager and adds it as an
UndoableEditListener to a JTextField:


  UndoManager undoManager = new UndoManager();
  JTextField tf = ...;
  tf.getDocument().addUndoableEditListener(undoManager);

UndoManager maintains an ordered list of edits and the
index of the next edit in that list. The index of the next edit is
either the size of the current list of edits, or if
undo has been invoked it corresponds to the index
of the last significant edit that was undone. When
undo is invoked all edits from the index of the next
edit to the last significant edit are undone, in reverse order.
For example, consider an UndoManager consisting of the
following edits: A b c D.  Edits with a
upper-case letter in bold are significant, those in lower-case
and italicized are insignificant.





Figure 1


As shown in figure 1, if D was just added, the
index of the next edit will be 4. Invoking undo
results in invoking undo on D and setting the
index of the next edit to 3 (edit c), as shown in the following
figure.





Figure 2


The last significant edit is A, so that invoking
undo again invokes undo on c,
b, and A, in that order, setting the index of the
next edit to 0, as shown in the following figure.





Figure 3


Invoking redo results in invoking redo on
all edits between the index of the next edit and the next
significant edit (or the end of the list).  Continuing with the previous
example if redo were invoked, redo would in
turn be invoked on A, b and c.  In addition
the index of the next edit is set to 3 (as shown in figure 2).

Adding an edit to an UndoManager results in
removing all edits from the index of the next edit to the end of
the list.  Continuing with the previous example, if a new edit,
e, is added the edit D is removed from the list
(after having die invoked on it).  If c is not
incorporated by the next edit
(c.addEdit(e) returns true), or replaced
by it (e.replaceEdit(c) returns true),
the new edit is added after c, as shown in the following
figure.





Figure 4


Once end has been invoked on an UndoManager
the superclass behavior is used for all UndoableEdit
methods.  Refer to CompoundEdit for more details on its
behavior.

Unlike the rest of Swing, this class is thread safe.

Warning:
Serialized objects of this class will not be compatible with
future Swing releases. The current serialization support is
appropriate for short term storage or RMI between applications running
the same version of Swing.  As of 1.4, support for long term storage
of all JavaBeans™
has been added to the java.beans package.
Please see XMLEncoder.
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close