I got this from a user posting to the nbusers mailing list. Anyways the main
idea is to make it easier for new users to find the post/pre init/creation
custom creation code editors. This question comes up a lot on the list....I'll
quote from the list.
I've seen this question come up a few times, so it might be worth
investing a little bit of time investigating how to make the "custom
code" feature easier to find for beginners.
What might be nice would be for the editor to display a dialog when a
user attempts to edit a guarded block, explaining to them how to go
about editing guarded blocks. This would probably be fairly easy to
implement, and would be more useful than simply "beeping" at the user
Beyond that, it would also be nice to give the user the option to open
custom code editor from this dialog, possibly giving them the choice of
which type of custom code ("pre-init", "post-init", etc.) should be
edited for which component.
Even better would be to automatically open the appropriate editor
automatically when the user starts typing in the guarded block, copying
the current content of the guarded block, so that the changes are
reflected in both the .java and .form files. I suspect this might be
difficult to implement, though, since it may be difficult to determine
which type of custom code should be edited, and for which component.
Smarter guarded blocks for form: when the user tries to edit guarded blocks ask
if they would like to jump to a components pre/post init/creation or custom
creation code editor. If the user isn't on a line referencing a specific
component ask the usr for the component and which type of custom code they would
like to add pre/post init/creation or creation code. If the user is on a line
referencing a component ask the user which type of code section they would like
to edit for this component. If on a line with two components (1 being passed as
a parameter or something to another component) as which of those componets to
edit which code type for. If the cursor is on a line where a brace begins a
code segment then ask the user which component in the segment and starting line
they would like to edit which custom code type for.
This should make it easier to manipulate the components created and initialized
by the form editor guarded code. It will definitely make it easier for the new
users. There should also be some type of an explanation for the users sake so
they don't ask wonder what this is about. Maybe even make the description
lengthy and give it it's own textarea and scrollpane....real lengthy explanation
A follow-up posting, from Frederick Barachant to the same thread, had another
"And what if the editor created non guarded folds for each custom code that
would be used to fill the right things under the hood?
Something like a "pre-init' marked fold before a component which, when edited,
would fill the pre-init in the interface. If the component is
moved/changed/whatever, the code could be moved/changed accordingly.
It would 'just' mean that the editor would have to be aware of modifications
inside specific folds. Not only that would be nice to everyone, but also it
would lower entry barrier to such code, make it acceptable to people that would
like to edit more of the code simply, without having to go through the
trees/tabs/scrollerbars.and maybe be enough so people whine much less on guarded
i think that should to have some option for disable the feature(Guarded Block).
crued: thanks for adding my contribution, you saved me some clicks. :)
I have one thing to add to what i said in the mailing list. I always hated the
custom code frame. It is modal, thus you can't navigate through existing code
for documentation or code to copy/paste and you don't have all the features of
the editor. All this makes the edition of code for those parts a pure pain in
Going through folds would at least permit us to edit those parts in a much more
natural way. Natural for us and smoother for you, i believe.(but please pardon
my complete noobness in the netbeans API)
Exploring how to ease the custom code editing, we realized the easiest way is to
provide a dialog showing complete code for a selected component and allowing to
insert and edit custom code by providing empty lines between the lines of
guarded content. This brings all custom code editing to one place (includes
custom code for property value, pre/post code for properties, and various
pre/post code for the component itself) and makes the navigation easier.
Trying to do this in whole initComponents method would be overly complex to
manage, and unclear how to invoke/hide in the source editor (the editable folds
could not be enabled all the time, and also could hardly be non-modal).
Allowing the editing on the level of components in a dialog seems a reasonable
compromise. It is not like editing the code in the editor directly with no
restrictions, but it makes the custom code management much easier. Here I'd like
to stress that almost all code modifications/additions can be done *outside* the
initComponents method, with full editor features, completely under user control.
There are really just few cases that require to modify the initComponents method
code inside, and quite rare require to write some bigger chunk of code there. So
the goal is not to provide the full featured editing experience for the custom code.
The best thing is that the code customizer dialog has just been integrated to
6.0 dev build :) (Not necessarily in the final shape yet.)
The dialog can be opened from context menu on selected component ("Customize
Code") and it allows to edit all aspects of the generated code (all types of
custom code, name of the variable, type of the declaration, etc). It also allows
to select other components without leaving the dialog.
One more thing we will consider is allowing to invoke the code customizer from
the source editor directly. That would be nice. (That's why I keep this
enhancement open for now.)
Tomas, will work be done with refactoring when renaming variables? I ask
because another issue I've been planning a bit involves variable renaming and
hooking form into refactoring.
I think I filed a similar issue re this before; couldn't the editor be smarter about *inserting* into guarded blocks without explicitly adding blank lines the way
the mobility pack does. I.e. user presses enter in guarded block and they get a new line they can type into. After all, it's modification of the generated code
that's problematic; not insertions.