Community
Participate
Working Groups
Build ID: I20070503-1400 Steps To Reproduce: With the attached zipped eclipse project: The view on the left is the ListView and contains a ComboViewer that contains groups bound to a GroupModel model. The view on the right is the GroupView and contains a ComboViewer that contains Brokers bound to a Group model. 1. With the group AUD-123 selected in the ListView, select a broker in the GroupView comboViewer. 2. Change the selection in the ListView to group CAD-123 and select a broker in the GroupView comboViewer. 3. Now change the selection in the ListView back to AUD-123 and notice that the previously selected broker for the group gets nulled out by the binding. More information:
Created attachment 67404 [details] Test eclipse project illustrating problem
ComboViewer will generate a selection change event when its old selection cannot be preserved. This happens when you switch between groups. If ComboViewer wasn't final, you could write this in GroupView.java to avoid the selection change event: final ComboViewer comboViewer = new ComboViewer(composite, SWT.BORDER){ protected void handleInvalidSelection(ISelection invalidSelection, ISelection newSelection) { // ignore } }; Unfortunately, ComboViewer is final, and we cannot change that for 3.3 since we are well past the API freeze. It should be possible though to make a private copy of ComboViewer and go from there. For 3.4, we should look at this in more detail and come up with an easier to understand story. Debugging this made my head hurt.
Created attachment 67660 [details] One workaround that avoides ComboViewer altogether I noticed that ComboViewer was final too, so here's a 100% Databinding-based approach to doing the same thing as ComboViewer -- attaching a model to a Combo. Some notes/thoughts: - This is so easy to do because of: WritableList and WritableValue - Our current viewer story never uses dbc.bind() but rather just chains observables together. The consequence is that you can't use our update strategy objects to intercept updates to viewers in order to emit log messages or insert breakpoints into the data binding pipeline. Attaching a WritableList / WritableValue pair to a Combo and using dbc.bind, makes the pipeline explicit and transparent again.
Boris, I'm sorry this made your head hurt. :-) I assigned the bug to myself because I was working on it. I guess I should have added a comment too. :-) BTW, this is the Combo order of evaluation bug we spoke about at EclipseCon and that I agreed to create a snippet illustrating. (But Geoff did that for us. :-) Basically, the problem is that removing all items in a Combo also clears the Text/selectionIndex. So either you have to make sure that the items observable is always updated first, and then the text/selection, or you have to create a wrapper that remembers the selection and tries to reset it after the items is set.
and tries to reset it after the items is set. ==> and tries to reset it after the items observable (the set of valid values in the Combo) is updated.
Geoff, does this solve your problem?
Yes, it does solve my problem. Thank you very much. I am getting a fairly significant flicker in certain cases when switching between models I can live with that over the nulling out of values :-).
(In reply to comment #7) > Yes, it does solve my problem. Dave's solution or mine?
I went ahead and used Dave's solution.
Boris, do you want to call this bug RESOLVED/FIXED now or retarget it against viewers for 3.4?
*** Bug 127424 has been marked as a duplicate of this bug. ***
May be related to bug 251611
Both this bug and bug 251611 are caused by Combo's behavior of clearing the text / selection index whenever the items are changed. *** This bug has been marked as a duplicate of bug 251611 ***
