I actually think the behavios is correct. If a file is grayed out, it doesn't mean it is not part of the project.It is.
What is means is, it is not being compiled in the current selected configuration. It could be compiled using a different
configuration. So I think it is reasonable that find also searches these files.

This is not about "not finding" files which are excluded from the current configuration it is about marking them the
same way it is done in Project Explorer.

Please try with Java+CVS and you will see that file which are changed under CVS will be marked with the same color they
are marked in Projects Explorer.

I am reopening this issue as it is serious usability issue if you have a huge project you cannot understand which files
you should not look at and which you can just ignore (as they are not used by Code Model in current configuration). Try
to find something in boost project and you will understand my point. 
As we do not have Find Usage feature on place I think we should implement this coloring in Search Results

changing platform to all. It is not PC specific.

OK, I've now spend quite a bit of time on this bug to see what can be done and I'm finding serious usability issues with the concept itself of using text color to signal whether a file is active in a project or not. The current implementation also limits the the way it can be used throughout the IDE.

Concept: using text color to signal whether a file is active in a project or not is a usability issue because it conflicts with for instance version control states that is using colors like green, blue, etc. to signal different VC states. Try to put a project under version control and select a few files to not be included in the project, and you will see the filename color is pretty much random. Sometimes it is colored by VCS and sometimes by CND project. Conclusion: it is a bad idea to use black/gray color in CND projects to signal a state. It often lies and there is no consistency if project is under VC.

Implementation: the current implementation has some logic in the code that provides the logical view and it makes a determination of what color to use. This code is obvious not called when a file is viewed in Find view, File view, Version Control view, Editor tab, etc. VC is using AnnotationProvider to override getHTMLName() in nodes which ensures the right text color is used (pretty much) everywhere the filename is viewed. VC registers this AnnotationProvider and gets called based on some logic in master filesystem and a notifier it also overrides. Besides that it is not a public API, we could implement our own AnnotationProvider and do the same, but it won't work because VC absorbs all calls to getHTMLName() and our implementation will never get called. And even if we got around all these issues, we will have trouble notifying the clients when our state has changed. You will end up with a mess of different colored file names in different views.

Conclusion: since the concept of using color to signal a CND state in itself is flawed and because of the implementation issues, I will close this as will not fix. I believe the fix is to somehow signal whether a file is active in a project in some different manner than the color of it's name. Once we have figured out what that should be, we need NB to provide a proper architecture  to support this if necessary. An idea is to badge the icon with a special badge that indicates the file is not active (similar to how errors are badged). This won't conflict with others, as far as I know. It will also require that NB fixes the above issues or provide an infrastructure that allows us to do this in all the views.

I guess we still want to fix it somehow. Next release....