PIRL.TreeTable
Class JTreeTable.TreeTableCellEditor
java.lang.Object
javax.swing.AbstractCellEditor
javax.swing.DefaultCellEditor
PIRL.TreeTable.JTreeTable.TreeTableCellEditor
- All Implemented Interfaces:
- Serializable, CellEditor, TableCellEditor, TreeCellEditor
- Enclosing class:
- JTreeTable
public class JTreeTable.TreeTableCellEditor
- extends DefaultCellEditor
TreeTableCellEditor implementation.
An editor that can be used to edit the tree column. This extends
DefaultCellEditor and uses a JTextField (actually,
TreeTableTextField) to perform the actual editing.
To support editing of the tree column we can not make the tree
editable. The reason this doesn't work is that you can not use the
same component for editing and renderering. The table may have the
need to paint cells, while a cell is being edited. If the same
component were used for the rendering and editing the component
would be moved around, and the contents would change. When editing,
this is undesirable, the contents of the text field must stay the
same, including the caret blinking, and selections persisting. For
this reason the editing is done via a TableCellEditor.
Another interesting thing to be aware of is how tree positions its
render and editor. The render/editor is responsible for drawing the
icon indicating the type of node (leaf, branch...). The tree is
responsible for drawing any other indicators, perhaps an additional
+/- sign, or lines connecting the various nodes. So, the renderer
is positioned based on depth. On the other hand, table always makes
its editor fill the contents of the cell. To get the allusion that
the table cell editor is part of the tree, we don't want the table
cell editor to fill the cell bounds. We want it to be placed in the
same manner as tree places it editor, and have table message the
tree to paint any decorations the tree wants. Then, we would only
have to worry about the editing part. The approach taken here is to
determine where tree would place the editor, and to override the
reshape
method in the JTextField component to nudge
the textfield to the location tree would place it. Since JTreeTable
will paint the tree behind the editor everything should just work.
So, that is what we are doing here. Determining of the icon
position will only work if the TreeCellRenderer is an instance of
DefaultTreeCellRenderer. If you need custom TreeCellRenderers, that
don't descend from DefaultTreeCellRenderer, and you want to
support editing in JTreeTable, you will have to do something
similiar.
- See Also:
- Serialized Form
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
JTreeTable.TreeTableCellEditor
public JTreeTable.TreeTableCellEditor()
getTableCellEditorComponent
public Component getTableCellEditorComponent(JTable table,
Object value,
boolean isSelected,
int row,
int column)
- Overridden to determine an offset where the tree would place the
editor.
The offset is determined from the
getRowBounds
JTree
method, and additionally from the icon DefaultTreeCellRenderer will
use. The offset is then set on the TreeTableTextField component
created in the constructor, and returned.
- Specified by:
getTableCellEditorComponent
in interface TableCellEditor
- Overrides:
getTableCellEditorComponent
in class DefaultCellEditor
isCellEditable
public boolean isCellEditable(EventObject event)
- Overridden to forward the event to the tree.
Returns true if the click count >= 3, or the event is null.
- Specified by:
isCellEditable
in interface CellEditor
- Overrides:
isCellEditable
in class DefaultCellEditor
Copyright (C) \
2003-2009 Bradford Castalia, University of Arizona