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.

Bug 150607 - Support an "event" for Forms
Summary: Support an "event" for Forms
Status: NEW
Alias: None
Product: javame
Classification: Unclassified
Component: Visual Designer (show other bugs)
Version: 6.x
Hardware: All Windows ME/2000
: P2 blocker (vote)
Assignee: Karol Harezlak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-18 11:07 UTC by bht
Modified: 2008-10-20 07:56 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bht 2008-10-18 11:07:11 UTC
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.
Comment 1 bht 2008-10-20 07:56:39 UTC
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.