Bug 2574 - [Cell Editors] CellEditor activation is not flexible enough (1GGEBXN)
Summary: [Cell Editors] CellEditor activation is not flexible enough (1GGEBXN)
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: All Windows 2000
: P4 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: investigate, usability
Depends on:
Blocks:
 
Reported: 2001-10-10 22:39 EDT by Nick Edgar CLA
Modified: 2003-04-10 16:25 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Edgar CLA 2001-10-10 22:39:03 EDT
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.
Comment 1 DJ Houghton CLA 2001-10-29 19:01:37 EST
PRODUCT VERSION:
0.9

Comment 2 Nick Edgar CLA 2002-01-26 22:03:16 EST
There have been lots of complaints with the way this works, within OTI and on 
the newsgroup.  Should address for 2.0.
Comment 3 Nick Edgar CLA 2002-01-26 22:03:57 EST
Most people expect single click to activate the cell editor, and have the 
click go through to it.  Compare with Outlook.
Comment 4 Tod Creasey CLA 2002-03-14 11:41:20 EST
This PR is to do with click issues and is aa usability rather than 
accessibility issue. This does not affect navigation via the keyboard.
Comment 5 Randy Giffen CLA 2002-05-27 21:37:47 EDT
Defer
Comment 6 Randy Giffen CLA 2002-08-08 12:23:03 EDT
Reopened to investigate
Comment 7 Kevin Haaland CLA 2003-02-07 15:19:14 EST
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.
Comment 8 Andrew Irvine CLA 2003-04-10 16:25:29 EDT
This was addressed in R2.1