This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | NodeAction.DelegateAction in combination with Actions.Bridge does not enable properly | ||
|---|---|---|---|
| Product: | platform | Reporter: | cylab <cylab> |
| Component: | Actions | Assignee: | Petr Nejedly <pnejedly> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | abadea, jchalupa, jrechtacek, mmirilovic |
| Priority: | P2 | Keywords: | SIMPLEFIX |
| Version: | 5.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
Petr, I guess it looks as a regression caused your fix of issue 66976 in NodeAction. Could you please evaluate it? Thanks You're both right. The problem is that during event dispatch, the getter still returns wrong value. And it is side effect of my fix of #66976. Is there a specific reason for the updateState()-method not using the property change event-object? in this situation, using event.getNewValue() would have avoided the problem. on the other hand the enabled state should be changed before the event fireing, even if it is just to meet the expectations the name "propertyChanged" implies... > Is there a specific reason for the updateState()-method not using the property
> change event-object?
Yes, there is. Beans spec allows you to fire("name", null, null), or even to
file(null, null, null). Taking this into account that there are many different
event sources (action implementations) you don't controll, you'd have to check
for null and fallback to getter anyway. So it is cleaner to not depend ot the
value there.
Fixed: openide/nodes/src/org/openide/util/actions/NodeAction.java,v1.9 This is a blocker for the SQL editor in 5.5. I have a CookieAction in the editor toolbar (its context-aware delegate, actually) and it is not disabled disable when the cookie the action is sensitive to is removed from the node in the delegate's context. Please integrate the fix in the release55 branch. No problem. QA agrees with the integration into 5.5. The complete patch is available at http://www.netbeans.org/nonav/source/browse/openide/nodes/src/org/openide/util/actions/NodeAction.java?r2=1.10&r1=1.8&diff_format=u Backported to release55 branch: openide/nodes/src/org/openide/util/actions/NodeAction.java,v1.5.10.2.2.1 Thanks, verified. |
If you have a context aware action instance that is connected to a button over the ButtonBridge, it does not get enabled properly. This seems due to the combination of the DelegateAction.resultChanged()-implementation (around line 560 in NodeAction.java), where the enabled-property is set after the firePropertyChange call: public void resultChanged(LookupEvent ev) { boolean newEnabled = delegate.enable(nodes()); support.firePropertyChange(PROP_ENABLED, enabled, newEnabled); enabled = newEnabled; } and the implementation of the Bridge.propertyChange()-method (Actions.java~480), where updateState() is called discounting the new value: public void propertyChange(final PropertyChangeEvent ev) { //assert EventQueue.isDispatchThread(); if (!EventQueue.isDispatchThread()) { new IllegalStateException("...").printStackTrace(); } updateState(ev.getPropertyName()); } since this is implemented to just calling isEnabled() on the action (Actions.java~680), which is not set to the new state as seen above, the button is not correctly enabled: public void updateState(String changedProperty) { // note: "enabled" (== SA.PROP_ENABLED) hardcoded in AbstractAction if ((changedProperty == null) || changedProperty.equals(SystemAction.PROP_ENABLED)) { button.setEnabled(action.isEnabled()); } // (...) }