Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 326200 - Disabled button in status bar becames enabled by itself; then handling fails with NotEnabledException
Summary: Disabled button in status bar becames enabled by itself; then handling fails ...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.6   Edit
Hardware: Macintosh Mac OS X
: P3 normal (vote)
Target Milestone: 3.7 M3   Edit
Assignee: Scott Kovatch CLA
QA Contact: Silenio Quarti CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-24 17:18 EDT by Sergey Bushkov CLA
Modified: 2010-10-21 17:36 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Bushkov CLA 2010-09-24 17:18:24 EDT 
Build Identifier: 3.6, 20100617-1415

A command was added to status bar:

<extension point="org.eclipse.ui.menus">
  <menuContribution locationURI="toolbar:org.eclipse.ui.trim.status?after=HEAD_GROUP">
    <toolbar id="...">
      <command ...>
...

Handler is enabled and disabled depending on application state; the command and button are enabled/disabled correctly when state is changed.

When certain actions are performed in eclipse, e.g. when a file is opened in editor, the button suddenly becomes enabled. When user clicks the buton, an exception is logged:

Failed to execute item com.klocwork.inforceeclipse.errorhandling.statusBarSyncNotification

org.eclipse.core.commands.NotEnabledException: Trying to execute the disabled command <id>
    at org.eclipse.core.commands.Command.executeWithChecks(Command.java:469)
    at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
    at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
...

Yes, the command and handler are still disabled. 

I tried to debug it, and it appears that the WorkbenchWindow.run() method first tries to disable toolbar (not separate buttons), and then enables toolbar back after operation is complete.

The cocoa implementation of ToolBar.setEnabled(false) simply disables all buttons, and then ToolBar.setEnabled(true) enables all buttons, even if they were disabled before (see ToolBar.enableWidget).

Other implementations (e.g. GTK) of ToolBar.setEnabled keep enabled state of buttons separately.

I believe this must be fixed in SWT; but also can be fixed in WorkbenchWindow - wondow can restore buttons' state based on commands state.

Reproducible: Always
Comment 1 Silenio Quarti CLA 2010-09-27 12:01:55 EDT 
Yes, this should be fixed in SWT.

Scott, I believe we can check our state bits to fix this.
Comment 2 Scott Kovatch CLA 2010-09-27 18:02:40 EDT 
I think all we need is 

 item.enableWidget(enabled && item.getEnabled());

in Toolbar.enableWidget(). ToolItem.setEnabled() should check the enabled state of its parent, too.
Comment 3 Scott Kovatch CLA 2010-09-27 18:14:28 EDT 
Fixed > 20100927.