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 propose the fact that editor display also the context. Example: display the content of initComponents in three 3 parts: the first one is read only, the second one is the place where you can introduce your code (the pre-code or the post-code) and the third part that is read only. I will post an image, explaining more clearly what I propose.
Created attachment 12388 [details] editors with context
Seems that my issue has not been seen/remarked by your team. So I hope that by adding a comment, it will receive the expected attention.
A proposal which I've been considering is to handle the preInit, postInit, etc code more like event handlers. To add a handler for an event, you click on the event type in the Forms editor property inspector. NB registers the event handler for you, creates the new method, and takes you to the new method in the main editor. You can make changes to the code at any time, as with other methods. Contrast this with the way postInit code is edited. Again you click in the property inspector, but instead you get a small editor with limited functionality. The code you type in is NOT editable from the full-featured, main editor. If you discover that you want to make changes, you have to switch back to the Forms editor, bring up the inspector for the component, and go back into the small postInit code editor. Editing postInit code could be made to work the same way as event handling code. Clicking on the postInit box in the inspector would add a new method (perhaps something like "jButton1PostInit()", for instance), add a call to the new method in initComponents(), and take you to the new method in the main editor. The new method would be editable from the main editor at any time - no more trip back through the Forms editor. I believe this idea has advantages over other proposals for partial/full editability of initComponents(): * It is consistent with a usage scenario that is already familiar to most developers. * It doesn't require a major change, such as arbitrarily guarded portions of initComponents(), and therefore should be easier to implement. * It makes use of similar, existing functionality, so again, should be relatively painless to implement.
Yes, this makes sense. Before implementing we should make this proposal match up with issue 23675 - so we could possibly do it in future as well.
*** Issue 58634 has been marked as a duplicate of this issue. ***
This was implemented in Customize Editor. Select component in design, invoke popup menu and choose Customize Code...