Community
Participate
Working Groups
TableViewerImpl installs a FocusListener on CellEditors, which calls applyEditorValue() on focusLost events. This FocusListener must be removed since applying the editor value is not always the wanted behavior on focusLost. Subclasses of CellEditor already handle focus loss in an extensible way: they install their own FocusListener and call a hook method focusLost() (which can be extended or reimplemented by subclasses with special needs). To support content assist in table cells (such as in the Change Method Signature dialog), we need to stay in editing mode even while the proposal list has focus. This is currently not implementable, since TableViewerImpl deactivates the CellEditor even if the CellEditor's focusLost() is reimplemented. The fix is to simply remove the redundant FocusListener in TableViewerImpl.
I think this would be a significant behaviour change for everyone who is using our cell editors - in 3.0 we have already had a lot of problem with some subtle changes to widgetDefaultSelect that generated a slew of problems. Any behavioural changes need to be considered carefully and post 3.0.
Marking later as these needs to be more carefully considered
Reopening now that 3.0 has shipped
I would appreciate if this could be looked at in the 3.3 cycle. It makes e.g. code assist in CellEditors very hard to implement nicely.
Maybe now it's a good time to think of this once more. In M3 if we integrate the Widget-Independency (bug #154329) we will refactor the Table/TreeEditorImpl completely and it is a use case for EditorActivation (bug #87733) which I'd like to integrate into EditingSupport.
Tod/Boris why do we need we have our own FocusListener attached to the editor-control? We are already attaching an ICellEditorListener isn't that enough? I think this would solve the problem Markus is referring to, right I've tested a little but and could find any thing not working as before from a usablility?
Once bug 181828 is fixed, this bug transforms into a request to make CellEditor#dependsOnExternalFocusListener() API, such that third-party CellEditors can also profit from the fix.
Boris, thoughts? We didn't have any complaints from people since we shiped 3.3 so I think we could savely make this API.
(In reply to comment #8) > Boris, thoughts? We didn't have any complaints from people since we shiped 3.3 > so I think we could savely make this API. +1 for making it API.
*** Bug 212232 has been marked as a duplicate of this bug. ***
Fix released to HEAD.
Verified by code inspection using I20071211-0010.
*** Bug 183627 has been marked as a duplicate of this bug. ***
