Community
Participate
Working Groups
I20080429-0100 Steps to reproduce (in the site view) - add the test update site: http://update.eclipse.org/testUpdates - in the filter search for "releng" - select the match, and notice that the match and all its parents are selected with the check box. - click install and notice the error. It appears like we have tried to install not only the feature but also all the elements from the category thus explaining the error. What I found weird is that the selection should not have checked the box of the category, but just fill it with a square.
This may be a timing problem between the checkbox container code and the filtering code. Will investigate after test pass for M7.
>What I found weird is that the selection should not have checked the box of the >category, but just fill it with a square. when the filtering job resets the viewer content, we need to catch this and invoke the check state changed listener so that the check state of the parent containers can be reset accordingly. Right now the code that manages the check boxes has no idea that filtering occurred and it only knows about the old check state.
*** Bug 229665 has been marked as a duplicate of this bug. ***
Note for future...this is a similar problem found in bug 17907 bug 170521
Marking this bug fixed. What I fixed was the problem of considering all of the filtered IU's selected and opening up the wizard on the wrong set of items. What remains are a bunch of selection oddities involving the check marks when you filter and unfilter the list. I believe these to ultimately result from bogus assumptions made in ContainerCheckedTreeViewer about the state of its elements when preserving selections. I spent the better part of this afternoon trying different workarounds and each introduced its own new set of problems. So for M7, I'm not working around these issues. I opened bug 229735 to track this part of the problem and will give it another look early in RC1.
