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.
For NB 6.0 we've integrated the GUI builder with the NetBeans refactoring infrastructure (infamous issue 48288), so the GUI forms and related resources are updated according to the structural changes done via Java refactoring features. We implemented the initial set of refactoring scenarios, but there are still some scenarios left. (Actually the area of refactoring is quite complex and can hardly be ever covered to the full extent.) We use this issue to collect refactoring scenarios not yet supported by the GUI builder. Anybody is welcome to add comments/ideas. Whenever we implement a new scenario, we'll also add a note here. Here are some of the scenarios not supported at this moment: - Copying GUI form class - Updating embedded custom code (entered by the user in the GUI builder) - Renaming an event handler method (via Rename refactoring) - Renaming an @action method - Renaming a bean property, etc. For the most recent list and for more details see: http://wiki.netbeans.org/wiki/view/GUIBuilderRefactoring
Does renaming inside of an event handler method work? In the nightly build I'm working with right now(200706220000), when I try to refactor something inside of a generated event handler by using refactor>>rename on the right-click menu, it tells me that the event handler method is a protected block so it can't.
I think this scenario should work, but it should only work currently with a special property set. you'll need to use a cmd line switch: -J-Dform.refactoring=true or add it to the netbeans.conf options for your build until this stuff is considered final this the switch will no longer be needed.
Might have spoken too soon. I think this is still one of the unsupported operations. If you look in the message of issue it says renaming the method is unsupported. I know other variables and things which are used inside the event handler will be renamed, but I don't think renaming the method itself works if this is what you mean.
Renaming the event handler method itself is not supported, but it should work _inside_ the method where the code is not protected. It does not work now due to a bug (see issue 105649). Also note that the cmd line switch is no longer needed, GUI refactoring is on by default.
*** Issue 105981 has been marked as a duplicate of this issue. ***
*** Issue 113162 has been marked as a duplicate of this issue. ***
*** Issue 122605 has been marked as a duplicate of this issue. ***
*** Issue 122873 has been marked as a duplicate of this issue. ***
*** Issue 121923 has been marked as a duplicate of this issue. ***
*** Issue 125999 has been marked as a duplicate of this issue. ***
*** Issue 130099 has been marked as a duplicate of this issue. ***
*** Issue 131668 has been marked as a duplicate of this issue. ***
From above, issue 130099 and issue 131668 have been already fixed (implemented). Issue 105649 and issue 113162 fixed elsewhere (not refactoring bugs). See the URL (http://wiki.netbeans.org/wiki/view/GUIBuilderRefactoring) for the most current state of supported and unsupported refactoring scenarios.
*** Issue 146305 has been marked as a duplicate of this issue. ***
*** Issue 146306 has been marked as a duplicate of this issue. ***
*** Issue 149294 has been marked as a duplicate of this issue. ***
*** Issue 155153 has been marked as a duplicate of this issue. ***
Using Netbeans 6.5 with JDK6.0 Refactored the class names of some JPanel forms. The refactoring appeared successful but gave an error on compiling: couldn't find symbol! The output error message was referring to the old class file name, which no longer existed in the ,java files. To further complicate things, after a reboot of Netbeans, the guarded blue blocks have now disappeared and a reference to the old class name has now appeared where a reference to the refactored class name exited.
*** Issue 174314 has been marked as a duplicate of this issue. ***
*** Bug 105850 has been marked as a duplicate of this bug. ***