15 Understanding Power Edit Forms

This chapter contains the following topics:

15.1 Power Edit Forms

Power forms are Web-only application forms that, through the use of the subform control, enable users to view multiple, interrelated views of data, grids, and tab pages on one form and to pass logic between them. The tab pages can have their own business views (BVs), and these BVs can communicate with each other and can update based on data selection and changes that occur in other BVs on the form. In this way, you can simplify navigation tasks for users.

Power forms have these general properties:

  • All regular controls except a parent child control can be placed on a power form.

  • Multiple tab controls are permitted.

  • The maximize grid feature is supported for all grids.

  • All power form (and subform) errors and warnings are shown from the error button on the power form.

  • Power forms contain vertical and horizontal scroll bars.

JD Edwards EnterpriseOne offers two types of power forms: browse and edit. A power edit form with a grid enables users to update and enter multiple records simultaneously. Similar to a headerless detail form, a power edit form has only one BV.

See Also:

15.2 Power Edit Form Design-Time Considerations

These property values are particularly significant in the design of the power edit form:

  • Mapping Links

  • Transaction

Use the Mapping Links property to identify the data to pass between parent and child. For each data item, specify whether the data is to flow from parent to child, child, to parent, or both directions. You must set up a mapping for every child of the parent. Without the mapping, the power edit form probably will not work correctly.

15.3 Power Edit Events

These events can occur on the power edit form during runtime if the form contains a grid control:

  • Dialog is Initialized

  • Post Dialog is Initialized

  • Grid Record is Fetched

  • Last Grid Record Has Been Read

  • Clear Screen Before Add

  • Clear Screen After Add

  • Write Grid Line-Before

  • Write Grid Line-After

  • Post Commit

  • Notified by Child

  • End Dialog

These events can occur on the power edit form during runtime if the form does not contain a grid control:

  • Dialog is Initialized

  • Post Dialog is Initialized

  • Clear Screen Before Add

  • Clear Screen After Add

  • Add Record to DB - Before

  • Add Record to DB - After

  • Update Record to DB - Before

  • Update Record to DB - After

  • Post Commit

  • Notified by Child

  • End Dialog

15.4 Power Edit Form Runtime Processing

This section discusses how runtime processes power edit forms.

15.4.1 Dialog Initialization

When a power edit form is called, runtime initializes these items in this order:

  1. Thread handling

  2. Error handling process

  3. BV columns

  4. Form controls (FC)

  5. Grid fields

  6. Static text

  7. Helps

  8. Event rules (ER) structures

This flowchart illustrates the tasks that runtime performs after initializing these objects to complete dialog initialization, if the form contains a grid control:

Figure 15-1 Power edit form with grid control dialog initialization

Description of Figure 15-1 follows
Description of "Figure 15-1 Power edit form with grid control dialog initialization"

This flowchart illustrates the tasks that runtime performs after initializing these objects to complete dialog initialization, if the form does not contain a grid control:

Figure 15-2 Power edit form with no grid control dialog initialization

Description of Figure 15-2 follows
Description of "Figure 15-2 Power edit form with no grid control dialog initialization"

15.4.2 Dialog Clear

This list discusses how runtime clears the form in preparation to display retrieved data:

  1. If the form was called in Copy mode, clear the key (primary index) controls for which the Do not clear after add option was selected.

  2. If the form was not called in Copy mode, clear all FCs for which the Do not clear after add option has been selected.

  3. Fire the Clear Screen Before Add event.

  4. Fire the Post Dialog is Initialized event.

15.4.3 OK Button

OK is a standard button on power edit forms that appears by default. It causes runtime to validate the information on the form and update or add it to the database through JDEKRNL function calls.

This flowchart illustrates the tasks that constitute runtime processing for the OK button, if the form contains a grid control:

Figure 15-3 Power edit form with grid control OK button processing

Description of Figure 15-3 follows
Description of "Figure 15-3 Power edit form with grid control OK button processing"

This flowchart illustrates the tasks that constitute runtime processing for the OK button, if the form does not contain a grid control:

Figure 15-4 Power edit form with no grid control OK button processing

Description of Figure 15-4 follows
Description of "Figure 15-4 Power edit form with no grid control OK button processing"

15.4.4 Cancel Button

The Cancel button is a standard button on power browse forms that appears by default. When the user clicks it, runtime fires the Button Clicked and Post Button Clicked events in immediate succession. If no errors occur, runtime cancels any media objects that might be open. Also, if a manual transaction is in process, runtime attempts to cancel it as well. Then, runtime fires the End Dialog event and initiates the dialog close process.

15.4.5 Dialog Close

Power edit can be closed either by the user (typically by clicking the OK or Cancel buttons) or by the system. After performing any control-level close processing that might need to occur, runtime closes the form. If the event has not already occurred, runtime fires the End Dialog event. Then it performs these tasks in this order:

  1. Load form interconnect data from BV columns for database commit.

  2. Terminate error and thread handling.

  3. Terminate helps.

  4. Free all form structures.

  5. Destroy the window.