Widget is disposed Exception

November 11, 2010

When you encounter this exception after closing a view or an editor, and re-opening that view or editor, check to see if you have added a PropertyChangeListener to some outside bean and have forgotten to remove it in dispose() of the view or editor.

The bean is then still trying to send you property changed events, which will result in the above exception, since your widget (the destination of the event) was disposed on closing the view or editor.


HandlerUtil.getCurrentSelection pitfall

November 10, 2010

Today I stumbled across a seemingly innocent call of HandlerUtil.getCurrentSelection():

What I had was a handler that is called from a navigator tree context menu (command), that was shown only on clicking (and thus selecting an item in the tree):

public class MySuperDuperHandler extends AbstractHandler {

   @Override
   public Object execute(final ExecutionEvent event) throws ExecutionException {
      try {
         final MySuperDuperView myView = (MySuperDuperView) HandlerUtil.getActiveWorkbenchWindow(event).getActivePage().showView( MySuperDuperView.ID);

         final IStructuredSelection selection = (IStructuredSelection) HandlerUtil.getCurrentSelection(event);
         if (selection != null && !selection.isEmpty()) {
            // do some funny stuff here
         }

      } catch (final PartInitException e) {
         throw new ExecutionException("Error opening view:", e);
      }

      return null;
   }
}

Much to my surprise, selection was always null, although I had thoroughly selected an item.
The reason is, that when you open a view, the selection source is switched to the newly opened view.

So the solution is simple.
Just get the selection upfront, before opening the view:

public class MySuperDuperHandler extends AbstractHandler {

   @Override
   public Object execute(final ExecutionEvent event) throws ExecutionException {
      try {
         final IStructuredSelection selection = (IStructuredSelection) HandlerUtil.getCurrentSelection(event);

         final MySuperDuperView myView = (MySuperDuperView) HandlerUtil.getActiveWorkbenchWindow(event).getActivePage().showView( MySuperDuperView.ID);

         if (selection != null && !selection.isEmpty()) {
            // do some funny stuff here
         }

      } catch (final PartInitException e) {
         throw new ExecutionException("Error opening view:", e);
      }

      return null;
   }
}

UPDATE:

Reason why the HandlerUtil.getCurrentSelection() might also return null or is, that another view (or in my case, a stubborn editor) still has the focus, although I was clicking in the tree viewer of the navigator view and was opening a context menu on the selected item.

So just make sure, that the view that is meant to be your selection provider has the focus when you call HandlerUtil.getCurrentSelection().


Preference pages with stubborn messages

September 20, 2010

When implementing Preferences in an Eclipse RCP app, you’ll probably make use of org.eclipse.jface.preference.FieldEditorPreferencePage containing instances of subclasses of org.eclipse.jface.preference.FieldEditor.

Now, suppose you want to display a message to your user, telling her that she made a terrible mistake by selecting one of the field controls.
You might use FieldEditor.showMessage(USEFULL_MESS) to show the message and FieldEditor.clearMessage() to clear it.

But, unfortunately, the message won’t disappear. At least that’s what it does on my machine (Eclipse Helios, Windows 7).
What seems to happen is that showMessage() calls page.setMessage(USEFULL_MESS, ERROR) of the parent PreferencePage, silently adding the ERROR parameter. When you’re trying to clean the message by calling clearMessage(), it will in turn call page.setMessage(null) without the second parameter.

This has the effect that the message remains displayed (a flaw in org.eclipse.jface.preference.PreferencePage IMHO).

To work around this, I did the following:
Call getPage().setMessage(USEFULL_MESS, WARNING); when you want to display the message (which as a benefit gives you the possibility to specify the severity of the message), and call getPage().setMessage(null, WARNING); when you want to get rid of it.

By supplying null and the same message type parameter (WARNING), the message will disappear.

I would very much appreciate your comments on this issue, and whether you think this is a bug in Eclipse.

p.s. Does anybody care about a complete code example?


Hello world!

August 14, 2010

Welcome, stranger, to my weird world of software tinkering!

Since even my neighbor’s dog has it’s own blog nowadays, I couldn’t stand behind.
Hopefully, the well-disposed and gentle reader will find an occasional bone to chew on.