ok.. I'll do some tricks to speed up the action..

BTW Petr, have you found out why the action's enable method is called
multiple times when activated nodes change?

fixed on 23/Oct/2001..
since the properties need to be set to null only if the value is
non-null, I've added a check for that..
also added another performance speedup. The abstractCommandAction
should now collect the information only if any of the subclasses
listens on it..



Index: org/netbeans/modules/vcscore/actions/AbstractCommandAction.java
===================================================================
RCS file:
/cvs/vcscore/src/org/netbeans/modules/vcscore/actions/AbstractCommandAction.java,v
retrieving revision 1.5
diff -w -B -b -i -c -r1.5 AbstractCommandAction.java
*** org/netbeans/modules/vcscore/actions/AbstractCommandAction.java	24 Aug 2001 09:43:25 -0000	1.5
--- org/netbeans/modules/vcscore/actions/AbstractCommandAction.java	23 Oct 2001 07:35:53 -0000
***************
*** 87,94 ****
--- 87,98 ----
      }
      
      protected boolean createSupporterMap(Node[] nodes) {
+         if (getValue(GROUP_NAME_PROP) != null) {
              putValue(GROUP_NAME_PROP, null);
+         }
+         if (getValue(GROUP_DESCRIPTION_PROP) != null) {
              putValue(GROUP_DESCRIPTION_PROP, null);
+         }
          if (nodes == null || nodes.length == 0) {
              suppMap = null;
              return false;
***************
*** 170,175 ****
--- 174,184 ----
          }
   */
          // debug end
+         if (this.getClass().equals(AbstractCommandAction.class)) {
+             if (actionSet == null || actionSet.size() == 0) {
+                 return false;
+             }
+         }
          createSupporterMap(nodes);
          if (actionSet != null) {
              Iterator it = actionSet.iterator();

At first, to your question:
Yes, there are several subclasses of that action and they all
inherit that part of the behavoiur.
And since they are all NodeActions, they are checked on every
node change. Martin told me that it is some kind of optimalization
for VCS groups, but VCS groups are rare and this causes strange
effects.
The propery firing problem is caused by frequent setting of GROUP_*
properties to null, where propery change from null to null requires
fire of the change (null treated as "no value specified, ask the
bean")


One more question:
Who is actually using these properties? I didn't found any usage.
Oops, I've found one in the javacvs module and only in the case
of CvsCommit it is IMHO too little to do that kind of processing
during virtually all Actions enable()

Reopening until this gets resolved somehow.

no, the questions was: Why is the Action.enable() method called
multiple times on my popup(proly other as well) actions when the
ActivatedNodes change just once?

I think I fixed it, don't understand why you reopen it. The properties
are now set to non-null values only if the slected object is a
vcsgroup and are set back to null only once after the vcsgroup node is
deselected.. I wouldn't call that frequently any more..
Yes, it is used only during commit.

one more thing.. Currently the javacvs popup action
CvsClientAction.java calls Action.enable() in getpresenter() and in
performAction().. it is a hack I had to add because something was not
working.. I'll examin that if the situation improved..

OK, the answer is:
enable()/createSupporterMap() is called only once on each action
for a node change.

There are 7 such actions in my IDE which meant 14 redundant fires
which is fixed now. 

There are still 14 "IMHO redundant" calls to getValue but there
are surely much worse things in the IDE :-)

could you tell me which 7 actions are that?

I've written the abstractCommandAction with the intention that the
createSupporterMap() method gets called just once.. all the toolbar
actions should for example delegate the supportermap creation to the
abstractcommandAction.. exception are the actions used in popup menus
since these can't use it because of threading issues..

OK, one change in selected nodes and having line
System.err.println("createSupporterMap on " + this);
at the beginning of the createSupporterMap method resuled in:

createSupporterMap on
org.netbeans.modules.vcscore.actions.UpdateCommandAction@bd5df
createSupporterMap on
org.netbeans.modules.vcscore.actions.CommitCommandAction@6e4ba6
createSupporterMap on
org.netbeans.modules.vcscore.actions.AddCommandAction@2517bd
createSupporterMap on
org.netbeans.modules.vcscore.actions.RemoveCommandAction@35d2b2
createSupporterMap on
org.netbeans.modules.vcscore.actions.DiffCommandAction@6030f9
createSupporterMap on
org.netbeans.modules.vcscore.actions.HistoryCommandAction@258c74

The seventh is not here anymore because of your last improvement.

hmm.. that's a quite unpleasant.. these actions should delegate the
processing.. I'll take a look at it..

should be fixed now.. for all the actions in toolbar/menu (exclusive
the popup menu.. that's special case)
the createSupporterMap() method should be called just once..
fixed on 24/Oct/2001

Petr, could you please verify the bug ? Are you satisfied with Milos's
fix ? Thank you.

It seems Petr has no objections. Verified in development build of Net-
Beans 3.3 #200110301025.

Resolved for 3.4.x or earlier, no new info since then -> closing.