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.
Summary: | Smarter guarded blocks: 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 | ||
---|---|---|---|
Product: | guibuilder | Reporter: | _ wadechandler <wadechandler> |
Component: | Code | Assignee: | issues@guibuilder <issues> |
Status: | NEW --- | ||
Severity: | blocker | CC: | bleonard |
Priority: | P3 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
_ wadechandler
2006-01-16 22:30:11 UTC
A follow-up posting, from Frederick Barachant to the same thread, had another good idea: "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 blocks..." 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 the 4ss. 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. |