Community
Participate
Working Groups
The Combo widget should support a viewer so that a content provider and label provider can be used. The content provider would allow something other than Strings to serve as a model and ideally the label provider would allow images to be displayed along side of text.
Reassigning to UI.
Combo does not support images. There is an existing PR for this: bug 4510, but it has not been touched in a while so if you really need this you should annotate that PR. How are you using the Combo? Is it in a preference page? JFace has a FieldEditor abstraction for preference pages, and other components have written a ComboFieldEditor. We should consider pushing this down, and supporting objects with a label provider in addition to strings. Combos can also allow arbitrary editing in addition to picking from a predefined list. There would be no underlying model object in this case. It would have to give the value in the selection callback as a String in this case.
I would like to add a Combo to a composite outside of preferences which contains strings and images that refer to a custom object. For example, cars with a relevant image next to each car name. Are you sure this bug is a duplicate of bug 4510? 4510 only refers to ComboBoxCellEditor's whereas this one strictly covers the Combo widget. Regarding arbitrary editing, you could still have a separate model and provide something similar to an ICellModifier to handle when the value is changed. An example of a Combo that has a model is the JComboBox in Swing.
There are no plans for the UI team to work on this defect until higher priority items are addressed. If you would like to work on this defect, please let us know on the platform-ui-dev mailing list.
This is really an important viewer that we are missing here i don't know how this is not a high priority issue
possible fix in 33396
*** Bug 33396 has been marked as a duplicate of this bug. ***
Created attachment 7762 [details] Fix from bug 33396 Simple fix for this defect (from duplicate bug 33396). I've been using this class for some time, and it seems to work well.
Created attachment 7764 [details] A JUnit test for ComboControl This is a patch for org.eclipse.jface.tests.viewers in head. It contains new tests for ComboViewer. The new tests are almost identical to the ListViewer tests. Note: currently, ComboViewer fails the insertChild test.
Created attachment 7765 [details] Alternate ComboViewer implementation that shares its implementation with ListViewer Here's an alternative ComboViewer implementation. This moves the common code for ListViewer and ComboViewer into a common base class. This is much cleaner, but it is not well tested. This is API-compatibile with the other patch. The refactored version of ListViewer passes the test suites.
Created attachment 7766 [details] Copies of the refactoried classes (in case the previous patch doesn't apply)
Do you realize how embarrassing it is to explain to Swing programmers that we have to track model object indexing outside of the Combo? Using the Combo widget has been a royal pain so I hope this makes it into M8 :-).
The patch needs work: Overall: - API classes should not extend non-API classes AbstractListViewer: - should be public - missing Javadoc for class and its methods - AbstractListViewer's abstract methods should be protected, not package-visible ComboViewer - missing @since 3.0 tag - remove @author tag - can have org.eclipse.swt.widgets.Combo in imports (this wasn't done for List in order to disambiguate it from java.util.List)
Fixed in HEAD.
