The Selection Service

If you’re building plug-ins for the Eclipse platform, you’re more than likely going to need the selection service. The selection service, as you might have guess from the name, takes care of selections in the workbench. Selections happen all over the place. Selecting a file in the navigator results in a selection. Similarly, selecting a Java class or method in the Package Explorer also results in a selection. Selections can also come from other places, including text editors.

Making a view that updates itself based on the selection is relatively easy. The selection service implements the observer pattern; to be notified of selections, create an register a listener. Below, the createPartControl method for a workbench view registers a selection listener:

...
ISelectionListener selectionListener;
...
public void createPartControl(Composite parent) {
	listener = new ISelectionListener() {
		public void selectionChanged(IWorkbenchPart part, ISelection selection) {
			handleSelection(selection);
		}
	};
	getSite().getWorkbenchWindow().getSelectionService().addSelectionListener(selectionListener);
	// build the view
	...
}

The site provides an interface between the view and the workbench. Here, we’re asking the site to get the workbench window; from the workbench window, we get the selection service and ask it to add our listener. The corresponding removeSelectionListener should be invoked when the view is closed:

public void dispose() {
	getSite().getWorkbenchWindow().getSelectionService().removeSelectionListener(selectionListener);
}

Note that there can be multiple open workbench windows; the safest way to find the right one is through the part’s site. If you obtain a workbench window through PlatformUI, you could end up with a situation where a selection in one workbench window affects the state of a view in another. This results in weirdness for the user and a less than seamless experience.

The selection object that is delivered to the listener can be a few different kinds of things so you probably will need to inspect it and, based on the type of selection, decide what to do. The listener that I created passes responsibility for this on the handleSelection method:

void handleSelection(ISelection selection) {
	if (selection instanceof IStructuredSelection) {
		handleStructuredSelection((IStructuredSelection)selection);
	}
}

void handleStructuredSelection(IStructuredSelection selection) {
	Object first = selection.getFirstElement();
	if (first instanceof ThingThatICareAbout) {
		...
	}
}

In this case, the handleSelection method checks the type of selection. The type IStructuredSelection—which indicates that the selection comes from a tree, table, list, or the like—contains one more more selected objects. The handleStructuredSelection method demonstrates how the first selected element is extracted from the selection; what happens next is up to the application. I can update the view based on that selection, or choose to just ignore the selection event (which I tend to do this for selections that I don’t care about). There are several different types of selection, including ITextSelection, ITreeSelection (which specializes IStructuredSelection), IMarkSelection.

The final bit of the equation is the selection provider. You may need your view to provide selections for the workbench window. If you have, for example, a table viewer in your view, you can pretty easily get that table viewer to set the selection and invoke the listeners via the setSelectionProvider method (shown here in the createPartControl method for the view):

public void createPartControl(Composite parent) {
	...
	viewer = new TableViewer(parent, SWT.MULTI | SWT.H_SCROLL | SWT.V_SCROLL);
	...
	getSite().setSelectionProvider(viewer);
}

Note that your view will be its own consumer if you make it both a producer and consumer of events.

A more comprehensive treatment of the selection service is available as an Eclipse Corner article by Marc Hoffman. You can view the article here.