Swing TreeCellEditor Methods Call Flow

Help a friend fixed a bug. discovered the clear call flow of Swing tree editor. keep it here for future reference.



V0.2 (Correction, Jan.19, 2009):

Important: in the initialization part of a customized TreeCellEditor, one must implement an ActionListener and register it to the real editor Component’s listener list.

In the implementation, call stopCellEditing() and check the return value, if true, fire ChangeEvent to listeners’ editingStopped() methods.

A. User choose (click / select) a node for editing:

1. isCellEditable()

// [if return false, exit!]

2. getTreeCellEditorComponent()

// argument “Object value” is the initial (existing) value (model wrapped) of the selected node to be edited.

// here is the place to store the initial value

3. shouldSelectCell()

// returned value only affect the node will be highlight (mark as selected) or not.

B1. User finished editing (leave the node / select another node):

4. stopCellEditing()

// here is the place to:

// * get the editor status,

// * do validate if necessary

// * compare to the initial node value,

// * and set the new node value.

If return false, should no fire ChangeEvent to listeners, so no call to step 5.

5. getCellEditorValue()

B2. User canceled editing:

4. getCellEditorValue()

// the tree (swing framework code) retrieve the result for purpose not known yet.

5. cancelCellEditing()

0. addCellEditorListener()

[last some grievance only]:
Though Java docs is much better compare to MSDN docs. Some parts are still not good enough or hard to understand, especially some advanced features. Looks like these Java API designs are designed for the designer only, no intention for user's understanding. I guess that's why some experienced technical decision makers want to switch from Java to .Net - tired of try to understand the underline design. Just follow some examples and use the tools to drug&drop and it works. That's what VisualStudio.NET good at. Who cares how it designed, who cares bug fix!