| Summary: | [JFace] Need ComboFieldEditor | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | UI | Assignee: | Michael Valenta <Michael.Valenta> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | eclipse, Michael.Valenta, rolarenfan, sdavids, thomasf, Tod_Creasey |
| Version: | 2.0 | Keywords: | helpwanted |
| Target Milestone: | 3.3 M1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 149152 | ||
|
Description
Dani Megert
changed title from ComboboxFieldEditor to ComboFieldEditor One question. Why does updateComboForValue do the following if the value
wasn't found in the list?
if (entryNamesAndValues.length > 0) {
value = entryNamesAndValues[0][1];
}
I guess it's so you don't end up with a bogus value, if the pref somehow has
an invalid valud. Shouldn't it update the text as well?
Also, shouldn't getNumberOfControls() return 2 (the label and the combo)? Here my answers: - to comment 2: yes it should - I fixed my implementation - to comment 3: yes it should - also fixed I guess I should have better reviewed the code before copying ;-) Added original debug contributor to cc-list to comment as well. We use our copy of the ComboFieldEditor to edit the "Switch to perspective" options in debug UI.I refactored Debug UI at one point and CVS loses history when files are moved. I believe Joe wrote this code for us. Changing getNumberOfControls() to return 2 will cause it to lay out horizontally rather than vertically. Apparently this is advantageous for accessibility: JAWS reads the label if it's on the same row, but not if it's above the combo. But is this what you want? Maybe we should make horizontal vs. vertical layout an option. I would switch to the horizontal layout. When I copied the code I also copied to UI layout (I didn't want to introduce new LAF for almost the same thing). There are no plans for the UI team to work on this defect until higher priority items are addressed. There are currently no plans to work on this feature No plans to work on this item, but if there was a contribution, would it be considered for inclusion? Thanks Thomas we would certainly be interested in your help I was just looking through our TODO comments and noticed a reference to this bug. Appearently Team also has a copy of this field editor (from Debug). It looks like the only work here is to compare the copies to make sure they all do roughly the same thing and then release one into the UI. I'm happy to do the work of consolidating the 3 or 4 copies of this class into a single implementation in UI if there are no objections from Tod or Susan. Great for me Mike. fine by me Dani, have you since deleted the ComboFieldEditor you created? I could only find one in Team and one in Search that both state they were copied from Debug (which has since been removed as well). It would be good to know why these were no longer needed (i.e. perhaps there is a better alternative in which case making the ComboFieldEditor API would be a mistake). I found the other copy in org.eclipse.jdt.debug.ui. I am in the process of transferring that one to JFace since Dani has made some fixes to address Nick's comments. It turns out there were also some bug fixes made by Dani to the Search copy and I will incorporate those as well. >Dani, have you since deleted the ComboFieldEditor you created?
No, I was Search component lead back in the old days and it was the copy that I've put into Search that triggered this bug.
I have released the ComboFieldEditor to JFace. It is based on a combination of the Search and JDT/Debug copies. I have updated Team as well and entered bug 149996 and bug 149999 for Search and Debug. *** Bug 42258 has been marked as a duplicate of this bug. *** |