モジュール java.desktop
パッケージ javax.swing.undo

クラスUndoManager

java.lang.Object
すべての実装されたインタフェース:
Serializable, EventListener, UndoableEditListener, UndoableEdit

public class UndoManager extends CompoundEdit implements UndoableEditListener
UndoManagerは、UndoableEditsのリストを管理し、編集結果を選択してその内容を元に戻したり再実行したりできます。 UndoManagerに編集結果を追加する方法は2とおりあります。 1つはaddEditメソッドを使って直接編集結果を追加する方法、もう1つはUndoableEditListenerをサポートするBeanにUndoManagerを追加する方法です。 次のコード例では、UndoManagerを作成し、これをUndoableEditListenerとしてJTextFieldに追加します。
   UndoManager undoManager = new UndoManager();
   JTextField tf = ...;
   tf.getDocument().addUndoableEditListener(undoManager);
 

UndoManagerは、編集結果の順序付きリストと、このリスト内の次の編集結果のインデックスを管理します。 次の編集結果のインデックスは、現在の編集結果のリストのサイズか、undoが呼び出されている場合は前回取り消された重大な編集内容のインデックスになります。 undoが呼び出されると、次の編集結果のインデックスから前回の重大な編集結果までのすべての編集結果が逆順に取り消されます。 たとえば、A b c Dという編集結果から成るUndoManagerがあるとします。 アルファベットの大文字で表された編集結果(太字)は重大な編集結果、アルファベットの小文字で表された編集結果(斜体)は小さな編集結果です。

図1
図1

図1に示すように、Dが追加されたばかりの場合、次の編集のインデックスは4になります。 undoを呼び出すと、Dに対してundoが呼び出され、次の編集のインデックスが3 (cを編集)に設定されます。次の図を参照してください。

図2
図2

前回の重大な編集結果はAです。undoを再度呼び出すと、cb、およびAに対して、この順番でundoが呼び出され、次の編集結果のインデックスが0になります。次の図を参照してください。

図3
図3

redoを呼び出すと、次の編集結果のインデックスから次の重大な編集結果(リストの末尾)までのすべての編集結果に対してredoが呼び出されます。 先ほどの例の続きで、redoを呼び出した場合、Ab、およびcに対して、この順番でredoが呼び出されます。 また、次の編集結果のインデックスが3に設定されます(図2を参照)。

UndoManagerに編集結果を追加すると、次の編集結果のインデックスからリストの末尾までのすべての編集結果が削除されます。 先ほどの例の続きで、新しい編集結果eを追加すると、編集結果Dに対してdieが呼び出されたあと、この編集結果がリストから削除されます。 cが次の編集結果に組み込まれていない場合(c.addEdit(e)の戻り値がtrueの場合)、またはcが次の編集結果で置き換えられる場合(e.replaceEdit(c)の戻り値がtrueの場合)、次の図のようにcの後ろに新しい編集結果が追加されます。

図4
図4

UndoManagerに対してendが呼び出されると、すべてのUndoableEditメソッドに対してスーパー・クラスの動作が適用されます。 この動作の詳細については、CompoundEditを参照してください。

このクラスは、ほかのSwingのクラスとは異なり、スレッドに対して安全です。

警告: このクラスの直列化されたオブジェクトは、今後のSwingリリースと互換ではなくなる予定です。 現在の直列化のサポートは、短期間の格納や、同じバージョンのSwingを実行するアプリケーション間のRMIに適しています。 1.4では、すべてのJavaBeansの長期ストレージのサポートがjava.beansパッケージに追加されました。 XMLEncoderを参照してください。