Community
Participate
Working Groups
Currently the assumption of the TreeTableViewer is that it is sufficient to provide an array of CellEditor objects corresponding to the columns. While this works in many situations it doesn't seem to fit with the rest of the pattern of delegation in the JFace structure. I suggest the addition of an interface akin to the ITableLabel provider which can provide a CellEditor for a given item and column and allow the consumer to provide this interface to the Viewer. This would be fairly straight forward to setup inside of the activateCellEditor function inside TreeEditorImpl. This is of interest as it would provide facility similar to what is in the properties view but with a more general architecture based on the ContentProvider framework.
Changed the summary (note that TableTree is deprecated).
I think the same issue exists for the TableViewer as well.
See http://www.eclipsezone.com/eclipse/forums/t59401.html for the hoops you have to go through now to get this effect.
This is the right reference to the discussion http://www.eclipsezone.com/eclipse/forums/t59419.html I would suggest slightly different approach that works for me. I don't use setCellEditors() and getCellEditors() methods at all. A CellModifier already has getValue() and modify() methods so it knows what kind of data is contained in a cell and how to work with it. I extended the ICellModifier interface with a public CellEditor getCellEditor( Object element, String property ) method and changed activateCellEditor() method in the TableEditorImpl class: private void activateCellEditor() { if( null == cellModifier ) return; String property = columnProperties[ columnNumber ]; if( ! cellModifier.canModify( tableItem, property )) return; cellEditor = cellModifier.getCellEditor( tableItem, property ); if( null == cellEditor ) return; In this case even canModify() call may be omitted since null cellEditor clearly indicates that cell cannot be modified.
(In reply to comment #4) > This is the right reference to the discussion > http://www.eclipsezone.com/eclipse/forums/t59419.html > > I would suggest slightly different approach that works for me. I don't use > setCellEditors() and getCellEditors() methods at all. A CellModifier already > has getValue() and modify() methods so it knows what kind of data is contained > in a cell and how to work with it. I extended the ICellModifier interface with > a public CellEditor getCellEditor( Object element, String property ) method and > changed activateCellEditor() method in the TableEditorImpl class: > > private void activateCellEditor() { > if( null == cellModifier ) > return; > > String property = columnProperties[ columnNumber ]; > > if( ! cellModifier.canModify( tableItem, property )) > return; > > cellEditor = cellModifier.getCellEditor( tableItem, property ); > > if( null == cellEditor ) > return; > > In this case even canModify() call may be omitted since null cellEditor clearly > indicates that cell cannot be modified. > The problem arising here is also addressed in bug #142655 where multiple cell-editors are available for one column no matter whether it is a Tree or a Table
This bug can be closed because since the patch from bug 149193 was released into head this is possible see EditingSupport#getCellEditor(Object element).
Marking as fixed.
