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.
Generated forms, lazily initialized, support the handling of some events already. "// write pre-init user code here" is a pre-initialization event. It would be very useful to support a post-get event so that form field values can reflect the _current_ values of data fields, not only their values at form initialization time. With current technology, one has to write such code in commandAction() in the following way: // write pre-action user code here // ##### Example start ##### getFormStatus(); // ##### Additional, could be eliminated with enhancement long freeMemory = Runtime.getRuntime().freeMemory(); long freememoryKB = freeMemory / 1000; stringItemFreeMemoryKB.setText(String.valueOf(freememoryKB)); // ##### Example end ##### switchDisplayable(null, getFormStatus()); A better way of doing this would be as shown in the following code. The advantages would be that the code is closer to the code of the form, easier to maintain, and that the additional initialization statement e.g. getFormStatus(); is eliminated. //<editor-fold defaultstate="collapsed" desc=" Generated Getter: formStatus "> /** * Returns an initiliazed instance of formStatus component. * @return the initialized component instance */ public Form getFormStatus() { if (formStatus == null) { // write pre-init user code here formStatus = new Form("Status", new Item[] { getStringItemFreeMemoryKB() }); formStatus.addCommand(getBackCommandStatus()); formStatus.setCommandListener(this); // write post-init user code here } // write post-get user code here ##### Enhancement ##### // ##### Example start ##### long freeMemory = Runtime.getRuntime().freeMemory(); long freememoryKB = freeMemory / 1000; stringItemFreeMemoryKB.setText(String.valueOf(freememoryKB)); // ##### Example end ##### return formStatus; } //</editor-fold> Currently the developer is not allowed to write code in this space.
I did not initially see the full importance of this. Lazy initialized or not, forms created by the Visual designer require more functionality to reduce the amount of code and duplication. If, for example, a form is accessed via multiple paths, one is forced anyway to write/generate a method that accesses the form and that populates the field, so that no code duplication occurs. So there is a requirement for an accessor method for the form object even in the eager initialized mode, because how otherwise can the developer centralize the code that populates form text items or text fields with fresh data every time the form is displayed? So there might be a check box "accessor method" in the form object's property sheet, that creates a new combination for eager initialized forms. In addition, one might extend my initial suggestion to form fields so their population with data is closer to the code where it belongs.