| Selection service is triggered on focus for a treeviewer ? [message #1059200] |
Fri, 17 May 2013 05:14  |
Eclipse User |
|
|
|
I have two independent tree viewer on two different parts in my application which on selection of a tree item are calling setSelection(item) for the selection service.
searchRsltTreeViewer.addSelectionChangedListener(new ISelectionChangedListener() {
public void selectionChanged(SelectionChangedEvent event) {
IStructuredSelection selection = (IStructuredSelection) event.getSelection();
// set the selection to the service
selectionService.setSelection(
//-- return always the first selected element
selection.getFirstElement());
}
});
My third part receives the selection then via @Inject
public void setSelection(@Optional @Named(IServiceConstants.ACTIVE_SELECTION) Object selObj) {}
So far nothing special. But the special here is the behavior. When in both tree viewers different objects are selected, my third part will receive the selection from the tree viewer that gets the focus. And by focus I mean focus not selection. The third part toggles between the two selected tree objects when clicking on the tree viewers scroll bars or the parts hosting them. Even better: when debugging, the switch in selection is done without running into the selectionChangeListener-code. If this is some sort of wanted behavior/feature, how can I suppress/dissable this. IMHO this should only happen when I explicitly put code for that under the @Focus.
But when I use the @Focus it is executed after the selection service is set ....?
|
|
|
|
| Re: Selection service is triggered on focus for a treeviewer ? [message #1059655 is a reply to message #1059515] |
Tue, 21 May 2013 02:34  |
| Eclipse User |
|
|
|
If I'm right, the bottom-line of your comment is, that switching between the active parts triggers a re-injection of the active selection in the parent context. In that case "separate keys" would be a work around, I agree, but that's exactly my point. I see that this behavior might be helpful in some situations, but I think it should be controllable in some way, like via the @Focus. My point is, that it is not a good idea to auto-trigger the re-injection (if it can not be controlled by the developer), when the tree receives the focus - it might be more reasonable on selection change ?
|
|
|
Powered by
FUDForum. Page generated in 0.05586 seconds
Home