Project: Eclipse_Platform_UI
Bug 249441 [Commands] Cut, copy and paste commands enabled when nothing selected.
Reported: 2008-10-02 04:23:16 | Status: verified fixed

Build ID: M20080911-1700 Steps To Reproduce: 1) In eclipse IDE show the error log then the outline view. 2) Close editors etc so that you have no java editor focused and there's nothing in the outline view. You want to arrange it so that it will say 'An outline is not available' and has focus. At this point, I think there's no active handler for the outline view so the default(s) takes over. So... 3) Go to edit menu. Note both 'cut', 'copy', 'paste' and 'select all' are enabled. 4) Run one of them, note error in the log (I've trimmed the bottom a little):- org.eclipse.core.commands.NotHandledException: There is no handler to execute for command org.eclipse.ui.edit.paste at org.eclipse.core.commands.Command.executeWithChecks(Command.java:485) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169) at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:247) at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:619) at org.eclipse.ui.menus.CommandContributionItem.access$10(CommandContributionItem.java:605) at org.eclipse.ui.menus.CommandContributionItem$4.handleEvent(CommandContributionItem.java:595) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033) More information: This isn't particularly noticeable in eclipse because just about every view/editor has normally bound handlers to these commands so you don't often fall back to the default handler. I noticed this because our RCP app has put the copy/paste commands in the toolbar and we also have lots of empty views open before the user opens anything, so its much more immediately obvious that somethings awry. I investigated this for a while because at first I thought I'd just screwed up our key handlers but eventually I figured out that this also happens in eclipse. What I found out is that these commands have a default handler registered, which is a HanlderProxy that wraps a WidgetMethodHandler. This evil looking class appears to be responsible. It doesn't bother firing events so the command's enablement isn't updated in response to focus/selection changing. Also the command appears to be enabled all the while. However, when it executes it frequently decides that it can't actually handle the command and hence this error gets logged. I guess being enabled all the while wouldn't be so bad if this handler fired events so that the command knew when the result of isHandled changed? I'm not entirely sure what this class is supposed to do, it looks like a bridge between SWT and Swing so firing events may prove difficult. Perhaps this should be a replaced by a handler scoped to an SWT_AWT instance using expresions?

Files changed in fix:
bundles/org.eclipse.ui.workbench/Eclipse UI/org/eclipse/ui/internal/handlers/WidgetMethodHandler.java