Community
Participate
Working Groups
AK writes on EC: i have a multi state cell editor (exactly like CheckBoxCellEditor - it just has n states, not 2) on each click the state changes. however, double clicks are ignored, which is not what i want. also, there seems to be a timeout on the single click. how do i turn it off? to summ up, here's the behavior i'd like to have: .you single click and the value changes imediately - like in a checkbox table (see jre preference page) .double click does exactly what single click does alternatively, single click is disabled, double click does the job how do i get that bahavior? thanks NOTES: NE (7/5/01 11:01:26 AM) EC reply: Unfortunately the TableViewer (and TableTreeViewer) hardcodes the delay and the double-click (non-)behaviour, in the TableViewerImpl class. See TableViewerImpl.handleMouseDown(MouseEvent) and handleMouseDoubleClick(MouseEvent). These are called by the listener in TableViewer.hookControl(). You might be able to fake it out by hooking selection or mouse events on the Table widget, and calling TableViewer.editElement(Object element, int column). You'll need to determine which column was selected by checking bounds of the various columns in the selected item. See TableViewerImpl.activateCellEditor(MouseEvent) for how it normally does this. You can get the element from the TableItem using getData() (although this is an internal implementation detail). However, if you do hook these events, the TableViewerImpl will still be doing its own handling, so you may have some strange interactions with the default behaviour. The only other alternative currently is to not set the cell editors in the viewer, but handle editing yourself (create your own TableEditor). You could still use the cell editors, but you would have control over when they are activated, rather than TableViewerImpl. This is a bit more work, but would give you the most control.
PRODUCT VERSION: 0.9
There have been lots of complaints with the way this works, within OTI and on the newsgroup. Should address for 2.0.
Most people expect single click to activate the cell editor, and have the click go through to it. Compare with Outlook.
This PR is to do with click issues and is aa usability rather than accessibility issue. This does not affect navigation via the keyboard.
Defer
Reopened to investigate
There are no plans for the UI team to work on this defect until higher priority items are addressed. If you are interested in working on this defect please let us know on the ui team's mailing list.
This was addressed in R2.1