reassigned to openide/actions. The action is active but is shown as
disabled. This bug is not the only problem of Find Action.  This is
problem of  Replace Action, Undo, Redo action too. 

*** Issue 35495 has been marked as a duplicate of this issue. ***

What regression? When did it happen?

Unfortunately, I can not specify 
the regression date - I was
in short vacation from the 
beginning of august.

OK, was it fine somewhen in July?

I'm just trying to ensure it was not caused by integration of issue
#27868.

I have an Aug 19 dev build in which the menu item is sometimes
enabled, sometimes not, according to no apparent pattern - even
changes for the same folder when repeatedly right-clicking it. The
menu item in the Edit menu also shows the same behavior.

I have no idea what might have caused the regression - some window
system change, perhaps, or something in actions - but anyway note that
the utilities module (FindActionManager) still uses the old-style
technique of calling FindAction.setActionPerformer upon focus change,
rather than the recommended ActionMap entry in the explorer.

I can reproduce in a [dev aug 11] build but not in a [dev jun 25]
build. I don't seem to have any intermediate dev builds lying around.
I also use Linux, BTW - RH Linux w/ Sawfish.

During almost all july, all was fine, I think -
I use almost _everyday_ new builds in my 
(production) work :-) an am happy :-)

I looked at it... and it seems it is caused by
change of org.openide.util.actions.CallbackSysemAction.java 1.30
..passing to Yarda

Hint:
At the line 315, there is called to clear of performers, and it is
also cleared just set performed for Find action.

Debug it the way you put a debug messages (dump stack) in
FindAction.setActionPerformer (by overriding it).

Created attachment 11392 [details]
Fix that seems to work

The problem is likely in wrong order of changes in TC.getLookup and
TC.Registry.getCurrentNodes. The desired behaviour is likely that when
currentNodes are changed, lookup shall already contain the correct
content. Attached patch shall fix it. I'll write some tests and then
apply it.

Checking in src/org/openide/windows/DefaultTopComponentLookup.java;
/cvs/openide/src/org/openide/windows/DefaultTopComponentLookup.java,v
 <--  DefaultTopComponentLookup.java
new revision: 1.14; previous revision: 1.13
done
Checking in src/org/openide/windows/TopComponent.java;
/cvs/openide/src/org/openide/windows/TopComponent.java,v  <-- 
TopComponent.java
new revision: 1.102; previous revision: 1.101
done
Processing log script arguments...
More commits to come...
Checking in
test/unit/src/org/openide/windows/TopComponentActivatedNodesTest.java;
/cvs/openide/test/unit/src/org/openide/windows/TopComponentActivatedNodesTest.java,v
 <--  TopComponentActivatedNodesTest.java
new revision: 1.3; previous revision: 1.2
done

*** Issue 35701 has been marked as a duplicate of this issue. ***

Merged to QBE200308200100:

Checking in src/org/openide/windows/DefaultTopComponentLookup.java;
/cvs/openide/src/org/openide/windows/DefaultTopComponentLookup.java,v
 <--  DefaultTopComponentLookup.java
new revision: 1.13.2.1; previous revision: 1.13
done
Checking in src/org/openide/windows/TopComponent.java;
/cvs/openide/src/org/openide/windows/TopComponent.java,v  <-- 
TopComponent.java
new revision: 1.101.2.1; previous revision: 1.101
done

Verified in dev build dev build [200308250100]. 

x

*** Issue 35701 has been marked as a duplicate of this issue. ***

Created attachment 73574 [details]
Actions Are disabled

I think I have to reopen this issue.
In my application based on the NB platform, sometimes the find(CTRL+F) and replace(CTRL+H) appears disabled.

I was able to reproduce it with my custom file type, with .txt file and .xml file
If I change TopComponent and then I come back to the first one, most of times they are not disabled anymore.
It is likely to be a NetBeans bug.

I have attached an image to clarify the problem

I'm decreasing the priority. As it isn't stopper for the 6.5 release. Please, be aware that this won't be fixed in 6.1
as it was released "long" time ago. 

If we'll find a fix then we can fix it for 7.0 or provide patch for 6.5. Maybe it should be tracked as new issue as this
one is really old...

Find action is provided by openidex module.

Please, reassign this issue to a component that the openidex module belongs to.
It is not the Utilities/Search.

This issue should be validated for the latest version of the NB and the use case described above by scanti.

http://spreadsheets.google.com/pub?key=tITVLlDs39AbmQ_n7Cq2mGQ&single=true&gid=5&output=html confirms that openidex -> Utilities/Search.

Sorry, but there is no plan to fix this issue. If it is important for you, feel free to re-open it, or contribute your patch.

This was originally FIXED in 3.6. scanti's is probably unrelated and may or may not be a bug in NB; should be filed separately if still reproducible.