Community
Participate
Working Groups
Eclipse Drop: December 19th Stable OS: Solaris 2.7 w/ Sun Recommended Patches HW: Sun Ultra 60 JRE: Sun 1.3.1 Motif: 2.1 CDE: 1.3 To Reporduce: Open Plug-in Perspective Open a plug-in prject manifest Choose something that will bring up editable fields in the "Properties View" Edit a field ending with <Enter> Failure Notice the property changes but the cursor is not released. Pressing <Esc> or clicking on some blacnk background will release the cursor. Consistant slighty annoying behavior under Linux-Motif.
Moving to Platform/UI as they deal with the Properties View.
Behavior not specific to Linux.
Can easily add a traverse listener to the cellEditor in the PropertiesSheetViewer. The question is why isn't this support part of the base JFace cell editors? Need to get with RG about this.
The complaint is that <return> does not end the cell edit in the Properties View. I can easily change the PropertySheetViewer to do this by listening for the SWT.TRAVERSE_RETURN event on the cell editor widget, but my question is why don't the JFace cell editors do this in the first place? Was it a conscious decision *not* to end the edit during <return> or just an oversight? I've run across the following code in both the TextCellEditor and the ComboBoxCellEditor: text.addTraverseListener(new TraverseListener() { public void keyTraversed(TraverseEvent e) { if (e.detail == SWT.TRAVERSE_ESCAPE || e.detail == SWT.TRAVERSE_RETURN) { e.doit = false; } } }); Whether doit is true or false seems to have no effect. Any idea why these lines are there? According to the SWT comments, it sounds like the doit field only matters for a dialog. Also, if I select an item from the list in a ComboBoxCellEditor and then press ESC, my value is not reverted to its original value (i.e., the selected value is applied instead). Again, was this a conscious decision?
From RG: Cell editors can also be used in dialogs (editor for a table widget for example) so the doit.false code below is required. I would not get the viewer to listen while the editor is active. Interaction with cell editors should be via their interfaces (ICellEditorListener etc.) It was a conscious decision to trigger applyEditorValue on return (see the ICellEditorListener comment). I don't see an easy solution for the problem. There are situations when using a text cell editor that return should trigger an apply but not end the edit. You could look at making the PropertySheetViewer end the edit on applyEditorValue. You would have to verify that the combo box cell editor sends this only on double click or return and not on item selection. The Esc problem sounds like an error in the PropertySheetViewer. It may go away if you end the edit whenever you apply. Note that you may run into complaints from others that they want to be able to change a value in the propety sheet and have it applied without ending the edit.
Defer
Reopen 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.
Is this still an issue in 3.2?
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
