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.
070725. 1. Create a new Java SE project. 2. File - New File - Swing GUI Forms - JPanel Form. 3. Select the project node, invoke Find in Projects. 4. In "Containing Text" enter "jpanel", select the Selection radio button, press Find. 5 matches are found in NewJPanel.java, but there is also a match in NewJPanel.form which is not found.
This is as designed. Why would you want to find a .form file specifically? It is not a file that contains reasonable *textual* content for users; it's never to be edited by the users. Anything you might want refer to is in the .java file from which you can easily switch to GUI design.
> Why would you want to find a .form file specifically? Because I need to rename a bundle message which was used in several forms and doing a Search / Replace in the whole package is faster than opening each form in the form editor.
You mean you search for a key of a bundle message which is used in multiple files? Then it is found in the java file, regardless if there is a .form file for it or not. You can then open it in GUI design if needed. We don't allow to edit the form files as a text in the IDE, so it does not make sense to show them in search results either.
> We don't allow to edit the form files as a text in the IDE I, as a user, don't care what you want to allow. I want to do a mass replace in the whole project, which includes form files. I can use NetBeans or Perl for that. If you tell me that the Find / Replace in Projects dialog just ignores form files, I will consider the dialogs unreliable. (If they skip form files, they may also skip other files, and I don't have the time to check.) I just won't use them and use Perl instead. I'm sure other power users will think the same.
I understand how you would like the bundle key rename work from user point of view. OTOH I'm not sure if it is a good idea to let the user search through and edit the .form files which are then very likely to get corrupted.
.form files are files that should not be modified directly by the user - that is why they are not editable directly, why they are treated as "secondary" by the IDE back-end and therefore ignored by the search routine. Access to the .form files is limited deliberately so I do not consider this a bug - I mark this bug as INVALID.
No problem for me, I can just use Perl. But I wonder why we call the thing an *integrated* development environment.
I have a few comments about this issue: First, I do not think this is a P1, does not delete user data, workaround exists (using external tools), relatively rare use case. P3, IMHO. But I think that the use case presented by Andrei is valid. I understand that letting the user to edit the .form files is potentially dangerous and it could open a can of worms, i.e. create requirements for better error recovery from user edits. I do not think we want to spend too much time improving this. But then again it is an xml format and not a binary file for a reason. IMO that reason is that is pseudo readable, diff is possible, it is potentially fixable by the user. I had a situation recently when I needed to fix .form files (because of a bug in IDE). I had to rename the .form file externally to be able to edit it in IDE (which in fact is the best xml editor on my disk at this moment), then change the extension back. That sucked. I am not very familiar with .form format. I forgot completely since I worked on form editor 7 years ago and the format has probably also changed. Any NetBeans user could make the manual changes that I made and I did not break the forms. "It is not a file that contains reasonable *textual* content for users" -- This is a false argument. If I create a file with extension .pavel how does the IDE know that the file has a "reasonable *textual* content"? What kind of new speak is that? :-) The file contains text and it's my problem to judge how reasonable is content of my text files ;-). I think showing the .form file by default would be a mistake, but search should operate on it and there should ideally be some way to open it in IDE in case you have to fix something. One idea is to show the .form files in search result in a different color, kind of like the files in build folder (maybe a different color then those in build folder). Another option would be to add a check box [ ] Search hidden files into the Replace dialog. Yet another option would be to use something like the "Ignored Files" in the System settings (with a better UI, of course) where the user would be able to un-hide files that are hidden by default. But these are just ideas, there may be a better solution. I am not sure how many other hidden files there are (I guess CVS folder is one example).
Replacing some resource reference, or fix some problem in the .form file are use cases that somehow justify the possibility to search/edit the .form files directly. (Even though these cases rather point to missing functionality elsewhere, e.g. structural search/changes like in java, e.g. some kind of "resource refactoring".) My original reaction was to the complaint that you can't find "jpanel" in .form file via text search. That's not really very useful. I'm not against allowing searching/editing .form files in certain situations. We allow the same thing with project meta data files too - but only in the Files view. So maybe the search/replace invoked on a folder in Files view could take into account and display data from .form files as well (i.e. from secondary files of data objects with text mime type). Showing the .form files as nodes in the search results is a bit tricky - it shows data objects now, not files (IIRC).
Current implementation involves the form files in the searching, but does it incorrectly. I'll close this bug as duplicate of the bug 185317, because both bugs should be fixed jointly. *** This bug has been marked as a duplicate of bug 185317 ***