Community
Participate
Working Groups
I found a strange behaviour when using ActionDelegates and listening to selection changes. Below is my scenario - I have a compilation unit editor open with an active text selection. - now I click on the packages view which has selected elements. As a result the method ActionDelegate#selectionChanged is called two times. first call: you get an empty structured selection also the reset method on SelectionService fires with the selection null, indicating that you are losing the selection. This null selection is magically converted into an empty structured selection in PluginAction.selectionChanged. I think this is not ok when the platform handles any kind of selection. It should propagate the null selection to my action delegate. Another strange behaviour of this conversion is that in ActionDelegate#selectionChanged the received selection is unequal the selection I retrieve from the IWorkbenchWindow.getSelectionService.getSelection. This one is still the old text selection. second call: now I get the structured selection from the packages view.
We have a workaround for this but which will fail if a someone emits an empty structured selection on purpose. Opt to raise to P2
Randy, could you investigate this one? selectionChanged should only be called once. We need to ensure that propogating null is allowed by the existing contracts and won't break existing clients.
The spec for IActionDelegate.selectionChanged indicates that null is a valid selection. However the following two classes in my workbench do not check for null: org.eclipse.jdt.internal.debug.ui.actions.WatchpointAction org.eclipse.debug.internal.ui.actions.CopyVariablesToClipboardActionDelegate
Agree that we should not be magically turning null into an empty selection. The null selection is fired because the selection service listens for part deactivation/activation and does not know that one will be followed by the other. This would require a change in the way we notify of part activation changes. I think it is now too late in the cycle for 2.0 to make such a changes. Suggest defer.
Defer
Reopen to investigate
History lesson: although we spec'ed that null could be passed, we originally did not pass null in the case of no selection (i.e. when the active part does not implement ISelectionProvider), but instead converted it to the empty selection. When we added the support to distinguish between no selection and empty selection, we did that using the mix-in interface INullSelectionListener. If the listener implements INullSelectionListener, we do pass null rather than converting to the empty selection (as per the spec for ISelectionListener.selectionChanged).
There is no plan to work on this currently
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
