How Runtime Processes the Grid Control
This subsection discusses how runtime processes the grid control.
Typically, runtime processes the grid control at these points in a standard workflow:
On control initialization (triggered by form initialization).
On grid population request (triggered conditionally by control initialization, Next, and Previous, and always by Find).
On row or control exit.
This flowchart illustrates the initialization process for a grid control:
Grid population occurs immediately after the initialization process if the option, Automatically Find On Entry is selected. The grid population process is also triggered when the user clicks the Find button or if you apply logic on an event to do so. If the fetch requires access to the form's BV only, then you can probably enable the engine to perform the fetch on its own. However, if you want to access other tables, you must set up and execute a custom fetch programmatically.
This flowchart illustrates the steps that occur when find is initiated:
This flowchart illustrates how the system performs an engine fetch:
This flowchart illustrates how the system creates the SQL statement:
Custom fetches are executed based exclusively on the ER associated with the Get Custom Grid Row event. The ER provides instructions for how to load a row, and runtime repeats the ER until you tell it to stop or it reaches the end of a page if page-at-a-time processing is enabled. To tell the engine to continue looping or not, include a call to Continue Custom Fetch in the ER. Set Continue Custom Fetch to True to run another loop; set it to False to exit the custom fetch loop. (Not calling Continue Custom Fetch is equivalent to setting it to false.)
Grid controls are used to display information. In some instances, information display is all the grid does, in which case, no more grid control processing occurs.
Grids can also be used to enable users to delete, edit, and add data as well. To enable any of these functions, the grid (and therefore the form) must be in Add or Update mode (Update mode is the default mode; add mode occurs either when the user clicks Add or a fetch fails to retrieve data). Furthermore for add and update capabilities, the grid must not be disabled; that is, the Disable Input option was not set at design time. Finally, to add data, the user must have an entry row (that is, a blank row) as well. Runtime automatically adds an entry row to update grids in the add and update modes as long as the No Adds on Update Grid option was not set at design time.
When the user tabs out of an entry row, runtime performs these functions in this order:
Clear the GC hash table.
Fire Last Entry Row to Grid.
Get the value from the GC and copy the contents into a new entry row.
This three-part flowchart illustrates how runtime processes the act of writing data from the grid and committing the change to the database:
This flowchart illustrates 21 CFR 11 validation:
This two-part flowchart illustrates grid data validation:
