Bugzilla – Full Text Bug Listing
| Summary: | ComboBox property editor fails when using filters | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Felix Velasco <felix.velasco> | ||||||
| Component: | Edit | Assignee: | Dave Steinberg <davidms> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | ahunter.eclipse, bokowski, davidms, Ed.Merks, lgrahek | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 305070 | ||||||||
| Bug Blocks: | 312961 | ||||||||
| Attachments: |
|
||||||||
|
Description
Felix Velasco
Video showing the bug in action, an image is worth a thousand words http://www.youtube.com/watch?v=Zvyfp6OtVOc Created attachment 148138 [details]
When modifying the filter, store and preserve the selection
*** Bug 304715 has been marked as a duplicate of this bug. *** *** Bug 193757 has been marked as a duplicate of this bug. *** Created attachment 161110 [details]
Yet another approach to address strange combo box behavior
Boris,
I think I need your help with this, if the contents of the combo are changed, and I set the selection correctly, later on the selection changes all by itself; I verified that widgetSelected is called in the base with a selection different from what I set. hence the delay needed to correct it yet again..
Boris is looking into some strange behavior in the underlying widgets which appears to be an SWT bug. It's effectively impossible to get perfect behavior with the underlying misbehavior... (In reply to comment #6) > Boris is looking into some strange behavior in the underlying widgets I filed bug 305070 for this. It's looking good now with the combo misbehavior fixed so I'll commit the changes, without a posted event. Hi Ed, to confirm, this issue is fixed by both the EMF change and the platform change in Bug 305070 Yes, the combination of fixes is needed. Ed and Dave, would it be possible to move this fix from HEAD (EMF 2.6) back into EMF 2.4 and run a build for us? We would then be able to patch the existing EMF 2.4 SR2 release with this fix. We have a customer requesting this fix. They feel it is of a critical nature for their application and need a fix in the Ganymede stream. I have asked the Eclipse team as well for Bug 305070 . Anthony, I'd suggest talking to Pat Huff about the issues and discussions surrounding funding for long term service and support. Of course in the end, anything is possible, but there's simply no incentive to justify the overhead that's involved in providing fixes to arbitrarily old releases along with the builds that contain them. Does it really make sense to address it in 2.4 but not 2.5? (In reply to comment #12) > Anthony, I'd suggest talking to Pat Huff about the issues and discussions > surrounding funding for long term service and support. Of course in the end, > anything is possible, but there's simply no incentive to justify the overhead > that's involved in providing fixes to arbitrarily old releases along with the > builds that contain them. > > Does it really make sense to address it in 2.4 but not 2.5? Hi Ed, yes, your are correct, long term support at Eclipse is indeed an issue and I have had many discussions with Pat about this. There has been no movement on this issue at Eclipse as you and I are aware. The issue remains however that I cannot create a fix of any kind for the customer without the code being committed into CVS at Eclipse.org. Hopefully we can set aside the long term support issue and focus on the task at hand for moving this fix back into 2.4. Yes, I suppose it could go into 2.5 as well, but the customer is not actually requesting this. Maybe I should look for help from Dave :-) ? (In reply to comment #13) > Maybe I should look for help from Dave :-) ? I take back this comment. Ed you are the project lead, I trust your judgment, let me know what you want to do with this request. For now all I am looking for is a yea or nea. There is movement on the issue of long term service and support at Eclipse. IBM is helping with those discussions and could help accelerate the movement. Of course patching arbitrary older releases is feasible as is producing builds from them, it's just that I simply cannot commit to doing either. Past experience says that if I do this one thing, the underlying problem will remain and it will rear its ugly head again and again; likely more often with each precedent. It seems better to let the problem come to a head. That will draw the focus it needs and will help illuminate a path toward a long term solution. OK, sounds good. For now I have my nea and I will take the issue back to Pat. When testing with the platform's M7, I discovered that a further change was needed now that the platform's keyboard handling doesn't kick in. Specifically, if the previous selection is filtered out from the list of remaining items, none of those items is selected where previous the default handling would select an item with a matching character. So I've added logic to select the first item in the list (which is the first item that matches the filter) whenever the previous selection is no longer present in the list. The fixes are available in 2.6 M7 or earlier. (In reply to comment #17) > When testing with the platform's M7, I discovered that a further change was > needed now that the platform's keyboard handling doesn't kick in. > Specifically, if the previous selection is filtered out from the list of > remaining items, none of those items is selected where previous the default > handling would select an item with a matching character. So I've added logic > to select the first item in the list (which is the first item that matches the > filter) whenever the previous selection is no longer present in the list. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf/plugins/org.eclipse.emf.common.ui/src/org/eclipse/emf/common/ui/celleditor/ExtendedComboBoxCellEditor.java?root=Modeling_Project&r1=1.7&view=log The original patch above was applied to ExtendedComboBoxCellEditor version 1.9. Ed's additional four line change made version 1.10. The SWT has helped us with a fix for Ganymede, now can we do the same for EMF? Pretty sure Dave said he would do any work required, hopefully Dave pinged you Ed. No, Dave has not discussed this with me. As a general point, I'm not happy if maintenance changes aren't incorporated into build. I'm not sure we can even produce 2.4 builds anymore... I'm also not comfortable with fixes in 2.4 that aren't also in 2.5. It seems completely arbitrary and likely to lead to yet another fix request later on down the road. Hi Ed, I hadn't said anything yet because I was waiting for the SWT fix, first. I didn't want to bother you about it without cause. On the first point, I'll happily produce a build containing any maintenance changes I introduce. I did that last time I added a fix to the 2.4 stream, which was many months ago (probably going on a year now). I can check to make sure we can still produce builds before checking anything in, if you'd like. The second point is not as easy to accommodate. I'll grant you that it's arbitrary, but it's not without cause. As you know, we have no fixes in the 2.5 stream, and have done no maintenance builds in that stream. So it seems even more arbitrary to start adding fixes there just because they're in the 2.4 stream. Also, the lack of any maintenance at all in that stream suggests that it's not so likely that anyone's going to ask for the fix there. If someone else does all the work, I'm certainly not going to block the effort. Someone else (that would be me) will definitely do all the work. Thanks Ed. I have created bug 312961 to track the fix in 2.4. |