Community
Participate
Working Groups
it would be really great if we could use the same MVC for ComboBoxes in tables like we do with normal ComboBoxes
Created attachment 24911 [details] ComboBox-Editor using CComboViewer
Created attachment 24912 [details] Viewer based upon CCombo instead of Combo
A quick look reveals that the current implementation of the ComboboxCellEditor now uses CCombo as its base control....
(In reply to comment #3) > A quick look reveals that the current implementation of the ComboboxCellEditor > now uses CCombo as its base control.... > I'm not sure what you are trying to say with this comment. Yes ComboboxCellEditor uses CCombo because Combo could not be resized on all platforms as far as I know. The 2 files only implement a viewer based on it so one can use the normal viewer programming when using TableViewer instead of a different implementation when dealing with tables. I've written this viewer for a datasource-binding framework I'm creating using viewers I can use the same logic in Tables-Forms than I do I normal Forms.
Eric, Tod, Boris what do you think about providing Viewer-based ComboBoxCellEditor?
Created attachment 55579 [details] The cell editor based upon a viewer Now that ComboViewer can deal with CCombo it would be a great thing to use that in Table/Trees
Eric would you mind passing over to me I'd like to include this in 3.4 time
I have no problem with hadning off my defects...;-) Done! Thanks Tom
Created attachment 66503 [details] A snippet if we add this class
Is there anything in the attached cell editor that would prevent its use in Eclipse 3.3?
no
Boris this is new API so you'll have to +1 or request me to change the API which IMHO is fairly straight foward. I'd like to get this out of my M4 queue ASAP
Looks good except for this: import java.text.MessageFormat; // Not using ICU to support standalone JFace // scenario This was likely copied from somewhere else, so I cannot blame you ;-). The problem is that java.text is not part of CDC Foundation 1.0 AFAIK.
(In reply to comment #13) > Looks good except for this: > > import java.text.MessageFormat; // Not using ICU to support standalone JFace > // scenario > > This was likely copied from somewhere else, so I cannot blame you ;-). The > problem is that java.text is not part of CDC Foundation 1.0 AFAIK. > Yes from ComboBoxCellEditor :-)
And what has to be used instead, we needed. The following Classes make use of MessageFormat in JFace: - ComboBoxCellEditor - DialogCellEditor - TextCellEditor - ExternalActionManager - JFaceResources
Released to CVS-HEAD > 20071107 I'm logging a seperate bug where we are going to fix the MessageFormat thingie
marking fixed the MessageFormat problem is tracked in bug #209108
Verified that it works on OS X but should it really be this ugly? screencap coming
Created attachment 85111 [details] Combo
the width of the second column should be adjusted but this is the is the same with ComboBoxCellEditor
(In reply to comment #10) > Is there anything in the attached cell editor that would prevent its use in > Eclipse 3.3? > I'm attempting to use this code in a 3.3-based plugin, but have a couple of small issues that I'm not sure are bugs or just due to subtle incompatibilities with 3.3 Looking at doSetValue(Object value), shouldn't it handle the case when the value is null, like this: protected void doSetValue(Object value) { Assert.isTrue(viewer != null); if (value == null) { viewer.setSelection(null); } else { viewer.setSelection(new StructuredSelection(value)); } } Also, the selectedValue is not updated as part of doSetValue() which seems to lead to a bug (at least on 3.3) where if the cell is activated via mouse click and then immediately tabbed out (without interacting with the CCombo), the cell editor returns null to doGetValue(). It seems it should be fixed by setting selectedValue in doSetValue(), like this: protected void doSetValue(Object value) { Assert.isTrue(viewer != null); selectedvalue = value; if (value == null) { viewer.setSelection(null); } else { viewer.setSelection(new StructuredSelection(value)); } } Are these legitimate bugs or just a function of trying to adapt this to 3.3?
Thanks Eric, those look like legitimate bugs. Could you file a new bug, attach a patch and I'll happily integrate it.
(In reply to comment #22) > Thanks Eric, those look like legitimate bugs. Could you file a new bug, attach > a patch and I'll happily integrate it. > Done, Bug 213315
verified that the new class is in in I20080430
