Community
Participate
Working Groups
In cases where the list of IUs is not available immediately it does not appear possible to correctly set the list if initially checked IUs. In the PDE target provisioning code (EditIUContainerPage) we use an AvailableIUGroup and attempt to configure the set of checked IUs. There is a call to setChecked() with the relevant items but somehow the values are being lost. Is there something wrong in the way that PDE is using AvailableIUGroup or something missing from its facilities or... The net effect is quite problematic for people with signicant targets as editing a container appears to lose all the selections forcing them to redo them. The workaround is it close the dialog and edit again but that does not always work (same race condition) and is not immediately obvious. This situation occurs quite frequently. Your help would be much appreciated.
Susan, would have a few cycles to look into this?
(In reply to comment #0) > In cases where the list of IUs is not available immediately it does not appear > possible to correctly set the list if initially checked IUs. In the PDE target > provisioning code (EditIUContainerPage) we use an AvailableIUGroup and attempt > to configure the set of checked IUs. There is a call to setChecked() with the > relevant items but somehow the values are being lost. > > Is there something wrong in the way that PDE is using AvailableIUGroup or > something missing from its facilities or... missing function. setChecked is documented to work only on visible/expanded items. I'm guessing you are calling it before the content provider has filled the viewer. You would also want to ensure that everything was expanded before you called the method. We do have a "synchronous" mode that the viewer can run in, which is used when we want to ensure that viewer contents are retrieved synchronously. This is what some of the test cases use when they are selecting items. For example, see InstallWizardTest.testInstallWizardUnresolved() around line 130-134. You could put the provider in synchronous mode, refresh and expand it, and then use setChecked to set the selections on the group. I realize this is not ideal, but will probably get you by. The challenge here is that the group is often used in asynchronous mode because we are talking to remote repositories and you can't reliably know when the content is all there.
In the long run we could probably hook listeners on the content provider to know when a fetch was done and then apply the selections, but I'm trying to suggest a hack for now until/unless we realize this is a general problem. Also, knowing whether the hack works will help us determine that this is indeed the problem.
I don't see this being fixed in 3.7
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
