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.
Product Version: NetBeans IDE 7.2 (Build 201207171143) Java: 1.7.0_06; Java HotSpot(TM) 64-Bit Server VM 23.2-b09 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb) User directory: C:\Users\Eric Balingit\AppData\Roaming\NetBeans\7.2 Cache directory: C:\Users\Eric Balingit\AppData\Local\NetBeans\Cache\7.2 The above is pasted from my 'about' section. My cpu is actually an i7, not amd64. I do not know if this is a bug or a consequence of safe re-factoring. When I change a JMenuItem 'Variable Name' in the [Component]-Properties window 'Code' tab, the parent JMenu's adapter and action overrides are dropped from initComponents(), but the handlers are left 'unused'. This occurs whether there is any reference to the child component(s) in the handlers or not. The unused handlers are now read-only and can only be safely deleted and redefined. Steps to reproduce: create a new java application add a JFrame Form add a JMenuBar to the form add a JMenu to the menu bar named 'parentMenu' add a JMenu to parentMenu called 'childMenu' add some JMenuItems to childMenu select childMenu select the 'Events' tab in the [childMenu]-Properties window define a couple of events for childMenu so code for adapter(s) and/or action(s) is generated change the name of one of the JMenuItems in childMenu adapter(s) or action(s) are no longer added to childMenu, however, the event handlers are still present in the code body and are squiggly marked as 'unused'. I have not attempted to produce the same behavior when dealing with parentMenu. The other JMenuItems in childMenu are not affected.
It is strange that changing a name of a component would remove events of another component. I'm not able to reproduce it following your steps, and have no idea what could cause the described behavior. I guess there must be something special in your setup or steps. Could you create a GUI form sample where it can be reproduced and attach it here? I.e. attach both form and java file and describe which component to rename to what name exactly. Thanks.
Created attachment 128525 [details] project where issue is reproducible and consistent
Sorry, my comment did not make it into the reply. To reproduce the behavior: Change the name of any jmenuitem in the edit > find... jmenu the actions of the find... menu disappear, but the handlers stay put (In reply to comment #2) > Created attachment 128525 [details] > project where issue is reproducible and consistent
Correction: The handlers can either be deleted and redefined, or they can be reused as they are, but the actions that lead to them need to be redefined.
Another thing that occurred to me is that code generation for both the edit menu and the find menu is serialized. I do not know if that helps or how it affects the code generation or the refactoring, but that was my first thought when I got your response. I tried changing the code-gen to serialize when attempting to reproduce the issue from scratch, but that did not cause the behavior. I hope it works for you with the project!
The cause of the problem is in the serialized components, i.e. there is a bug that events for serialized components are not loaded. I've fixed that. http://hg.netbeans.org/jet-main/rev/3af5e51df393 Please don't set the serialization option for the components unless you have a real special reason for that. It definitely makes no sense for the UI (Swing) components and is only causing troubles. We'd better disable this option completely, but it's not that easy since it's required by the JavaBeans spec.
Integrated into 'main-golden', will be available in build *201212040001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/3af5e51df393 User: Tomas Pavek <tpavek@netbeans.org> Log: #222867: workarounds for serialized components: reloading events and other properties after setting deserialized instance, more robustness to failures