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.

Bug 72777 - NodeAction.DelegateAction in combination with Actions.Bridge does not enable properly
Summary: NodeAction.DelegateAction in combination with Actions.Bridge does not enable ...
Alias: None
Product: platform
Classification: Unclassified
Component: Actions (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Petr Nejedly
Depends on:
Reported: 2006-02-17 15:15 UTC by cylab
Modified: 2008-12-22 17:38 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description cylab 2006-02-17 15:15:14 UTC
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, where the enabled-property is set after the firePropertyChange

        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 (,
where updateState() is called discounting the new value:

        public void propertyChange(final PropertyChangeEvent ev) {
            //assert EventQueue.isDispatchThread();
            if (!EventQueue.isDispatchThread()) {
                new IllegalStateException("...").printStackTrace();


since this is implemented to just calling isEnabled() on the action
(, 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) ||
            // (...)
Comment 1 Jiri Rechtacek 2006-02-17 15:38:50 UTC
Petr, I guess it looks as a regression caused your fix of issue 66976 in
NodeAction. Could you please evaluate it? Thanks
Comment 2 Petr Nejedly 2006-02-17 17:11:52 UTC
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.
Comment 3 cylab 2006-02-17 17:19:48 UTC
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...
Comment 4 Petr Nejedly 2006-02-17 18:47:09 UTC
> 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.
Comment 5 Petr Nejedly 2006-02-17 21:46:57 UTC
Comment 6 Andrei Badea 2006-02-27 13:04:52 UTC
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.
Comment 7 Petr Nejedly 2006-02-27 13:09:52 UTC
No problem.
Comment 8 Jaromir Uhrik 2006-02-27 13:20:55 UTC
QA agrees with the integration into 5.5.
Comment 10 Petr Nejedly 2006-02-27 16:58:24 UTC
Backported to release55 branch:
Comment 11 Andrei Badea 2006-02-27 17:05:56 UTC
Thanks, verified.