Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 177441

Summary:	[CellEditors] ComboBoxCellEditor API needs cleanup
Product:	[Eclipse Project] Platform	Reporter:	Chris Audley <chrisaudley>
Component:	UI	Assignee:	Platform UI Triaged <platform-ui-triaged>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	dlwhiteman, marek.zawirski, pombredanne, tom.schindl
Version:	3.2.2	Keywords:	helpwanted
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Chris Audley

2007-03-14 17:47:08 EDT

Build ID: M20070212-1330

Steps To Reproduce:
The ComboBoxCellEditor is excessively restrictive in its usage and seems to go out of its way to prevent you from working around its deficiencies.

A common request is a ComboBoxCellEditor that allows the user to enter arbitrary text -- like a ComboBox.  An often suggested approach is to override doGetValue and doSetValue to get the desired behaviour.  However, the applyEditorValueAndDeactivate method stands in the way.  This method uses "items[selection]" to format the error message even though the same information is available in "newValue" -- which would contain the right information for an edited CCombo.

Worse, the applyEditorValueAndDeactivate method is package private, so I can't even override and fix it myself if I want.  This is perhaps the biggest barrier to fixing this limited implementation.  I can't override it, and I can't call it from my own subclass.

All of the listeners should use methods in the CellEditor class to handle events, as the focusLost listener does.  This would allow subclasses to hook into the handlers, the listeners themselves can't be replaced in the CCombo because there are no-references to them.

Another thing, by default the CCombo used is not set to SWT.READ_ONLY, even though the design of the cell editor restricts usage to values in the CCombo selection list.  The default style should contain SWT.READ_ONLY.

Finally, if the most common reason to subclass this editor is to support an editable combo, why not just do it.  Its not like its hard to support both approaches.  If the argument to doSetValue is an Integer, use the current semantics, if its a String, assume an editable value.

More information:

Comment 1 David Whiteman

2007-03-21 15:12:54 EDT

I totally agree with this entire bug.  I was trying to do the same thing and am extremely frustrated.  Please allow the cell combo editor to better support arbitrary text.  This would be extremely important implement a spreadsheet kind of app that remembers previous entries but allows you to type new ones.  

Please, can we have this for 3.3?

Comment 2 David Whiteman

2007-03-21 15:50:24 EDT

I was able to somewhat work around my problem like this:

((org.eclipse.swt.custom.CCombo) comboCellEditor.getControl()).getText()

from within the modify() method of the cell modifier.  Not pretty, but it gets the job done for now.  I still think the API is extremely difficult to use if you are trying to allow for editable combo cell editors, and welcome any improvements you can make.

Comment 3 Eclipse Webmaster

2019-09-06 16:16:34 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

Comment 4 Eclipse Genie

2022-02-09 17:33:17 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.