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.
I would like to explain why I ask that feature. I was working on issues concerning the WizardPanels (split the classes into two distinc classes: One that extend the JPanel the other that implement the WizardDescriptor.Panel) Thus the new version of the WizardClass doesn't contains any reference to the UI part. As said, I had to split a Panel into two distinct part: 1) the Wizard Panel that implement only the Wizard 2) the UI Panel that extent the JPanel To do simple, I just copy/paste the class and give a new name to the just created class. With that new created class, I deleted all stuff concerning the UI. And I would like to keep necesary methods concerning the Wizard interface. I deleted the form file, I suppress the extend JPanel, But I was unable to delete methods that were automaticly generated by the form editor. I know that the solution was to delete added comment used to GUARD BLOCK by an external Editor. But I like to stay in NetBeans. My proposal of feature is the following: when I edit a source file that has no .form file, why the system is not proposing to delete the GUARD BLOCK COMMENT to be able to edit those part of code and manage it. If a .FORM file exists, GUARDED BLOCKS are propected against edition. If no .FORM file can be found, a dialog windows appears to ask you that normally a FORM file would be present but that NetBeans can't find it and it propose you to permit to edit part of code that is normally GUARDED BLOCKS. And say that user will not more be able to edit that source via the Form Editor.
Form editor could provide a feature like: throw away the .form file, remove all guarded blocks from .java file. But if there's no .form file, then there is no clue that the .java file was originally generated by form editor - form editor is not invoked for that file, the file is handled as normal java code. In such case, java module should provide a way to cancel protection in guarded blocks (with appropriate warning).
What's the current status ??
It's pending. Right now both java module and form editor modules are under heavy rewrite due to the new projects system integration. I am afraid that we aren't able to implement this feature in 4.0 release time frame. Sorry.
Don't be afraid. I understand that you are busy with the new project. Thanks for the feedback
Any news ? Will you have time to introduce it in NB3.6 ?
Java module does not know who created the guarded block. If the form file does not exist, the file is not handled by FormDataObject, but rather by the standard JavaDataObject. JavaDataObject has no clue that some guarded-blocks in the file are form-specific and could theoretically be removed. There might as well be other modules that create these guarded blocks and these guarded blocks are perfectly valid (e.g. beans module creates such guarded blocks in bean info class). So, to resolve this issue we either need to build some kind of new guarded blocks API that would allow Java module to get more info about whether the guarded block is still valid or not, or we could provide a generic "remove all guarded blocks" action on a file. The second option would of course be much simpler. This will need to be communicated accross several teams.