public class JFastTreeTable.TreeTableCellEditor
extends javax.swing.AbstractCellEditor
implements javax.swing.table.TableCellEditor
Constructor and Description |
---|
JFastTreeTable.TreeTableCellEditor() |
Modifier and Type | Method and Description |
---|---|
java.lang.Object |
getCellEditorValue() |
java.awt.Component |
getTableCellEditorComponent(javax.swing.JTable table,
java.lang.Object value,
boolean isSelected,
int r,
int c) |
boolean |
isCellEditable(java.util.EventObject e)
Overridden to return false, and if the event is a mouse event
it is forwarded to the tree.
|
addCellEditorListener, cancelCellEditing, fireEditingCanceled, fireEditingStopped, getCellEditorListeners, removeCellEditorListener, shouldSelectCell, stopCellEditing
public java.awt.Component getTableCellEditorComponent(javax.swing.JTable table, java.lang.Object value, boolean isSelected, int r, int c)
getTableCellEditorComponent
in interface javax.swing.table.TableCellEditor
public java.lang.Object getCellEditorValue()
getCellEditorValue
in interface javax.swing.CellEditor
public boolean isCellEditable(java.util.EventObject e)
The behavior for this is debatable, and should really be offered as a property. By returning false, all keyboard actions are implemented in terms of the table. By returning true, the tree would get a chance to do something with the keyboard events. For the most part this is ok. But for certain keys, such as left/right, the tree will expand/collapse where as the table focus should really move to a different column. Page up/down should also be implemented in terms of the table. By returning false this also has the added benefit that clicking outside of the bounds of the tree node, but still in the tree column will select the row, whereas if this returned true that wouldn't be the case.
By returning false we are also enforcing the policy that the tree will never be editable (at least by a key sequence).
isCellEditable
in interface javax.swing.CellEditor
isCellEditable
in class javax.swing.AbstractCellEditor