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.
NB refactoring doesn't work in Matisse code/forms. Since Matisse is an integral part of NB, I think this is a big bug. Here's my use case: I have a UI prototype with a few dozen classes spread over several package. Most of them are Matisse-generated forms and beans (i.e. I created some custom components using Matisse and made them beans, loaded them into the Matisse Palette and used them to create other forms.) The beans were in the package com.netforensics.ui.components. The forms using these beans were spread across various other packages. I decided a more appropriate name for the beans package would be, well, com.netforensics.ui.beans. I right-clicked on the package name and chose 'Refactor->Rename' and NB shows me the the list of all the classes that would be affected with the little message "137 errors" in parentheses (with no real visual clue as to which files in the list have the errors :-( Anyway, the errors are all due to Refactoring not going into Matisse generated code (and .form files) to make the necessary changes to the fullly-qualified bean class names Matisse uses everywhere! I can't even use Matisse itself to make the changes! I had to exit the IDE and use an external editor and manually make all the changes. Took about an hour :-( I'm running NB 6.0 daily (10/17 build) on Fedora 5, and JDK 1.6 build 100 (although this is just a missing 'feature'; I've come across this before in 5.x builds.)
*** This issue has been marked as a duplicate of 48288 ***
Fix it.
Does this mean it's not a duplicate after all or are you indicating that I should fix it myself because I pointed out that this bug is 2 years old? If it's the latter, I will refrain from opening issues in the future. thanks, tom
I have a similar problem in NB5.5. Trying to rename a form class which has Matisse-generated listeners does not change the names inside the listeners. The generated code is PanelETIButtons.this.btnWriteActionPerformed(evt); ^^^^^^^^^^^^^^^ This is the class which was renamed. Naturally this gives a compile error as this name doesn't exist. If you can't fix it, can you please give us a workaround which is better than "don't change names".
This is really a duplicate of 48288. To ptove: The workaround is to open the form and do whatever change to make the GUI builder regenerate the code according to the new class name. *** This issue has been marked as a duplicate of 48288 ***
>------- Additional comments from wrongway Tue Nov 7 14:32:31 +0000 2006 ------- > >Fix it. > >------- Additional comments from twolf2919 Tue Nov 7 15:15:55 +0000 2006 >------- > >Does this mean it's not a duplicate after all or are you indicating that I >should fix it myself because I pointed out that this bug is 2 years old? If >it's the latter, I will refrain from opening issues in the future. > >thanks, >tom For a starter, I'm not a Sun employee and have no affiliation. No I believe wrongway must have been saying fix it because I closed it as a duplicate of a true duplicate. Please read the bug and comments of a previous bug before reopening a bug marked as a duplicate. I and others have comments in issue 48288. I use the IDE and try to help out when possible. I'm hoping to get time to try to help out with this, but there is no need for comments like 'Fix It'. If one believes so strongly I suggest you try to get off your hump and use your own time as I plan on doing to make the IDE better because like I said: "I do not work for Sun". That is the beauty of open source. We have also been given NB for free, and it has so many features that it is unreal. Now: I'm waiting on the new infrastructure in 6.0 because I do not want to possibly waste my time to just rewrite it for 6.0 as I am unsure of the changes taking place, and I do not want to even bother until I get some stable 6.0 build with the new features and APIs.