Back to Contents

Array Display

Summary:

• Basics
  • The full list mode
  • The paged mode
  • Built-in sort
  • Built-in find
  • Built-in seek
  • Multi-range selection
  • Tree-view lists
  • Drag and Drop
  • List modification triggers
• Syntax
• Usage
  • Programming Steps
  • Variable Binding
  • Instruction Configuration
  • Default Actions
  • Data Blocks
  • Control Blocks
  • Control Blocks Execution Order
  • Interaction Blocks
  • Control Instructions
  • Control Class
  • Control Functions
• Scrolling Rows Up and Down (SCROLL)
• Examples
  • Full list mode example
  • Paged mode example

See also: Arrays, Records, Result Sets, Programs, Windows, Forms, Input Array

Basics

With DISPLAY ARRAY, you can let the user browse a list of records, using a static or dynamic array as the data buffer. The DISPLAY ARRAY instruction can work in full list mode or in paged mode. In full list mode, you must copy all the data you want to display into the array. In paged mode, you provide data rows dynamically during the dialog, using a dynamic array to hold one page of data. The full list mode should be used for a short and static list of rows, while the paged mode can be used for an infinite number of rows. Additionally, the paged mode allows you to fetch fresh data from the database.

The full list mode

In full list mode, the DISPLAY ARRAY instruction uses a static or dynamic program array defined with a record structure corresponding to (or to a part of ) a screen-array of a form. The program array is filled with data rows before DISPLAY ARRAY is executed. In this case, the list is static and cannot be updated until the instruction is exited.

The paged mode

In paged mode, the DISPLAY ARRAY instruction uses a dynamic program array defined with a record structure corresponding to (or to a part of ) a screen-array of a form. The total number of rows is defined by the COUNT attribute, which can be -1 to specify an infinite or undefined number of rows when the dialog starts. The program array is filled dynamically with data rows as needed during the DISPLAY ARRAY execution. The ON FILL BUFFER clause is required, to feed the DISPLAY ARRAY instruction with pages of data. The statements in the ON FILL BUFFER clause are executed automatically by the runtime system each time a new page of data is needed.

For more details about the paged mode, see the ON FILL BUFFER clause and also the Multiple Dialogs page.

Built-in sort

The DISPLAY ARRAY dialog implements built-in row sorting which can be used if the dialog is combined with a TABLE or a TREE container; when the end user clicks on a column header of the table, the rows are automatically sorted in ascending or descending order.

For more details about the built-in sort feature, see the Multiple Dialogs page.

Built-in find

The DISPLAY ARRAY dialog supports a built-in search to let the user find rows in the list by entering a value in a popup window.

For more details about the built-in find feature, see the Multiple Dialogs page.

Built-in seek

When the user types alpha-numeric characters on the keyboard during a DISPLAY ARRAY dialog, Genero will automatically seek to the next row where a character field contains a value that starts with the typed characters.

For more details about the built-in seek feature, see the Multiple Dialogs page.

Multi-range selection

DISPLAY ARRAY can support multiple row selection with the ui.Dialog.setSelectionMode() method. By default, the DISPLAY ARRAY instruction highlights only the current row. When multi-row selection is enabled, the end user can select one or several rows with the standard keyboard and mouse click combinations. The program can then query the DIALOG class for selected rows.

Tree-View lists

DISPLAY ARRAY can be used to implement the controller for a tree-view list widget. The tree node structure is defined by the program array rows, and the form must define a TREE container.

See the Tree Views page for more details.

Drag and Drop

DISPLAY ARRAY supports new control blocks to implement drag & drop operations.

See the Drag and Drop page for more details.

List modification triggers

The DISPLAY ARRAY dialog implements by default a read-only list of records: The end user can navigate in the list, but cannot modify the rows. The traditional Genero way to implement an editable list of record is to use the INPUT ARRAY dialog. However, INPUT ARRAY uses ergonomics that may not correspond to the end user expectations. Basically, a list controlled by an INPUT ARRAY is always in edit mode: the focus is in a field and the user can modify the current field. When moving up or down in the list, the edit cursor jumps to the upper or lower cell. Modern GUI applications usually implement read-only lists that can switch to edit mode when a specific action is fired. Genero supports four special triggers to control row insertion, appending, modification and deletion in a DISPLAY ARRAY dialog: ON INSERT, ON APPEND, ON UPDATE, ON DELETE. For more details, see Interaction Blocks.

DISPLAY ARRAY

Purpose:

The DISPLAY ARRAY instruction controls the display of a program array on the screen.

Syntax:

where dialog-control-block is one of :

{ BEFORE DISPLAY
| AFTER DISPLAY
| BEFORE ROW
| AFTER ROW
| ON IDLE idle-seconds
| ON ACTION action-name
| ON FILL BUFFER
| ON INSERT
| ON UPDATE
| ON DELETE
| ON EXPAND ( row-index )
| ON COLLAPSE ( row-index )
| ON DRAG_START ( dnd-object )
| ON DRAG_FINISH ( dnd-object )
| ON DRAG_ENTER ( dnd-object )
| ON DRAG_OVER ( dnd-object )
| ON DROP ( dnd-object )
| ON KEY ( key-name [,...] )
}
    dialog-statement
    [...]

where dialog-statement is one of :

{ statement
| EXIT DISPLAY
| CONTINUE DISPLAY
| ACCEPT DISPLAY
}

Notes:

1. array is a static or dynamic array containing the records you want to display.
2. screen-array is the name of the screen array used to display data.
3. help-number is an integer that associates a help message number with the instruction.
4. key-name is an hot-key identifier (such as F11 or Control-z).
5. action-name identifies an action that can be executed by the user.
6. idle-seconds is an integer literal or variable that defines a number of seconds.
7. row-index identifies the program variable which holds the row index corresponding to the tree node that has been expanded or collapsed.
8. dnd-object references a ui.DragDrop variable defined in the scope of the dialog.
9. statement is any instruction supported by the language.

The following table shows the display-attributes supported by the DISPLAY ARRAY statement. The display-attributes affect console-based applications only, they do not affect GUI-based applications.

The following table shows the control-attributes supported by the DISPLAY ARRAY statement:

Usage:

Programming Steps

The following steps describe how to use the DISPLAY ARRAY statement:

1. Create a form specification file containing a screen array. The screen array identifies the presentation elements to be used by the runtime system to display the rows.
2. Make sure that the program controls interruption handling with DEFER INTERRUPT, to manage the validation/cancellation of the interactive dialog.
3. Define an array of records with the DEFINE instruction. The members of the program array must correspond to the elements of the screen array, by number and data types. You can use a static or a dynamic array for a full list mode, but you must use a dynamic array for a paged mode.
4. Open and display the form, using an OPEN WINDOW with the WITH FORM clause or the OPEN FORM / DISPLAY FORM instructions.
5. If you want to use the full list mode, fill the program array with data, for example with a result set cursor, counting the number of program records being filled with retrieved data.
6. Set the INT_FLAG variable to FALSE.
7. Write the DISPLAY ARRAY statement block. When using a static array, specifying the number of rows with the COUNT attribute in the ATTRIBUTES clause.
8. If you want to use the paged mode, define the total number of rows with the COUNT attribute (can be -1 for infinite number of rows), and add the ON FILL BUFFER clause inside the instruction, and write the code to fill the dynamic array with the expected rows from fgl_dialog_getBufferStart() to fgl_dialog_getBufferLength().
9. If multi-row selection is needed, call the ui.Dialog.setSelectionMode() method in BEFORE DISPLAY to enable this mode.
10. Inside the DISPLAY ARRAY statement, control the behavior of the selection list with BEFORE DISPLAY, BEFORE ROW, AFTER ROW, AFTER DISPLAY and ON KEY blocks.
11. After the interaction statement block, test the INT_FLAG pre-defined variable to check if the dialog was canceled (INT_FLAG = TRUE ) or validated (INT_FLAG = FALSE ). If the INT_FLAG variable is TRUE, you should reset it to FALSE to not disturb code that relies on this variable to detect interruption events from the GUI front-end or TUI console.
12. If needed, get the selected row with the ARR_CURR() built-in function.

Variable Binding

The DISPLAY ARRAY statement binds the members of the array of record to the screen array fields specified with the TO keyword. Array members and screen array fields are bound by position (i.e. not by name). The number of variables in each record of the program array must be the same as the number of fields in each screen record (that is, in a single row of the screen array).

Keep in mind that array members are bound to screen array fields by position, so you must make sure that the members of the array are defined in the same order as the screen array fields.

When using the UNBUFFERED attribute, the instruction is sensitive to program variable changes. This means that you do not have to DISPLAY the values; setting the program variable used by the dialog automatically displays the data into the corresponding form field.

01 ...
02   ON ACTION change
03     LET arr[arr_curr()].field1 = newValue()
04 ...

If the program array has the same structure as a database table (this is the case when the array is defined with a LIKE clause), you may not want to display/use some of the columns. You can achieve this by used PHANTOM fields in the screen array definition. Phantom fields will only be used to bind program variables, and will not be transmitted to the front-end for display.

Instruction Configuration

The ATTRIBUTES clause specifications override all default attributes and temporarily override any display attributes that the OPTIONS or the OPEN WINDOW statement specified for these fields. While the DISPLAY ARRAY statement is executing, the runtime system ignores the INVISIBLE attribute.

• HELP option
• COUNT option
• KEEP CURRENT ROW option
• ACCEPT option
• CANCEL option

HELP option

The HELP clause specifies the number of a help message to display if the user invokes the help while executing the instruction. The predefined help action is automatically created by the runtime system. You can bind action views to the 'help' action.

COUNT option

When using a dynamic array, the number of rows to be displayed is defined by the number of elements in the dynamic array; the COUNT attribute is ignored.

When using a static array or the paged mode, the number of rows to be displayed is defined by the COUNT attribute. You can also use the SET_COUNT() built-in function, but it is supported for backward compatibility only. If you don't know the total number of rows for the paged mode, you can specify -1 for the COUNT attribute (or in the SET_COUNT() call before the dialog block): With COUNT=-1, the dialog will ask for rows by executing ON FILL BUFFER until you provide less rows as asked, or if you reset the number of rows to a value higher as -1 with ui.Dialog.setArrayLength(). 

KEEP CURRENT ROW option

Depending on the list container used in the form, the current row may be highlighted during the execution of the dialog, and cleared when the instruction ends. You can change this default behavior by using the KEEP CURRENT ROW attribute, to force the runtime system to keep the current row highlighted.

ACCEPT option

The ACCEPT attribute can be set to FALSE to avoid the automatic creation of the accept default action. Use this attribute when you want to write a specific validation procedure by using ACCEPT DISPLAY.

CANCEL option

The CANCEL attribute can be set to FALSE to avoid the automatic creation of the cancel default action. Use this attribute when you only need a validation action (accept), or when you want to write a specific cancellation procedure by using EXIT DISPLAY.

Note that if the CANCEL=FALSE option is set, no close action will be created, and you must write an ON ACTION close control block to create an explicit action.

Default Actions

When an DISPLAY ARRAY instruction executes, the runtime system creates a set of default actions. See the control block execution order to understand what control blocks are executed when a specific action is invoked.

The following table lists the default actions created for this dialog:

The accept and cancel default actions can be avoided with the ACCEPT and CANCEL dialog control attributes:

01  DISPLAY ARRAY arr TO sr.* ATTRIBUTES( CANCEL=FALSE, ... )
02    ...

Data Blocks

Data blocks are dialog triggers which are invoked when the dialog controller needs data to feed the view with values. Such blocks are typically used when record list data is provided dynamically, with the paged mode of when implementing dynamic tree-views.

• ON FILL BUFFER block
• ON EXPAND block
• ON COLLAPSE block

ON FILL BUFFER block

The ON FILL BUFFER block is used to fill a page of rows into the dynamic array, according to an offset and a number of rows. The offset can be retrieved with the FGL_DIALOG_GETBUFFERSTART() built-in function and the number of rows to provide is defined by the FGL_DIALOG_GETBUFFERLENGTH() built-in function.

A typical paged display array consists of a scroll cursor providing the list of records to be displayed. Scroll cursors use a static result set. If you want to display fresh data, you can write advanced paged display array instructions by using a scroll cursor providing the primary keys of the reference result set, plus a prepared cursor used to fetch rows on demand in the ON FILL BUFFER clause. In this case, you may need to check if a row still exists when fetching a record with the second cursor.

Before starting a paged display array, you do normally count the total number of rows in the result set (SELECT COUNT(*)) and give this number to the dialog with the COUNT option or SET_COUNT() function. You can start the dialog with an undefined number of rows by specifying -1. The dialog will continue to ask for rows with ON FILL BUFFER until you provide less rows as expected for the page, or if you reset the total number of rows to a value different from -1 with ui.Dialog.setArrayLength().

 See Example 2 for a typical paged mode implementation.

ON EXPAND block

This block is executed when a treeview node is expanded (i.e. opened). Typically used to implement dynamic trees, where nodes are added according to the nodes opened by the end user. See TreeViews for more details.

ON COLLAPSE block

This block is executed when a treeview node is collapsed (i.e. closed). Typically used to implement dynamic trees, where nodes are added according to the nodes opened by the end user. See TreeViews for more details.

Control Blocks

• BEFORE DISPLAY block
• AFTER DISPLAY block
• BEFORE ROW block
• AFTER ROW block

BEFORE DISPLAY block

The BEFORE DISPLAY block is executed one time, before the runtime system gives control to the user. You can implement dialog initialization tasks in this block.

AFTER DISPLAY block

The AFTER DISPLAY block is executed one time, after the user has validated or canceled the dialog and before the runtime system executes the instruction that appears just after the DISPLAY ARRAY block. You typically implement dialog finalization in this block.

BEFORE ROW block

The BEFORE ROW block is executed each time the user moves to another row, after the destination row is made the current one.

When the dialog starts, BEFORE ROW will be executed for the current row, but only if there are data rows in the array.

When called in this block, the ARR_CURR()  function returns the index of the current row.

AFTER ROW block

The AFTER ROW block is executed each time the user moves to another row,  before the current row is left. When called in this block, the ARR_CURR() function returns the index of the current row.

Control Block Execution Order

The following table shows the order in which the runtime system executes the control blocks in the DISPLAY ARRAY instruction, according to the user action:

Interaction Blocks

• ON IDLE block
• ON ACTION block
• ON KEY block
• ON DRAG* and ON DROP blocks
• ON APPEND block
• ON INSERT block
• ON UPDATE block
• ON DELETE block

ON IDLE block

The ON IDLE idle-seconds clause defines a set of instructions that must be executed after idle-seconds of inactivity. This can be used, for example, to quit the dialog after the user has not interacted with the program for a specified period of time. The parameter idle-seconds must be an integer literal or variable. If it evaluates to zero, the timeout is disabled.

You should not use the ON IDLE trigger with a short timeout period such as 1 or 2 seconds; The purpose of this trigger is to give the control back to the program after a relatively long period of inactivity (10, 30 or 60 seconds). This is typically the case when the end user leaves the workstation, or got a phone call. The program can then execute some code before the user gets the control back.

01 ...
02   ON IDLE 30
03     IF ask_question("Do you want to leave the dialog?") THEN
04       EXIT DISPLAY
05     END IF
06 ...

ON ACTION block

You can use ON ACTION blocks to execute a sequence of instructions when the user raises a specific action. This is the preferred solution compared to ON KEY blocks, because ON ACTION blocks use abstract names to control user interaction.

01 ...
02   ON ACTION zoom
03     CALL zoom_customers() RETURNING st, cust_id, cust_name
04     ...

For more details about ON ACTION and binding action views, see Interaction Model.

ON KEY block

For backward compatibility, you can use ON KEY blocks to execute a sequence of instructions when the user presses a specific key. The following key names are accepted by the compiler:

An ON KEY block defines one to four different action objects that will be identified by the key name in lowercase (ON KEY(F5,F6) = creates Action f5 + Action f6). Each action object will get an acceleratorName assigned. In GUI mode, Action Defaults are applied for ON KEY actions by using the name of the key. You can define secondary accelerator keys, as well as default decoration attributes like button text and image, by using the key name as action identifier. Note that the action name is always in lowercase letters. See Action Defaults for more details.

Check carefully the ON KEY CONTROL-? statements because they may result in having duplicate accelerators for multiple actions due to the accelerators defined by Action Defaults. Additionally, ON KEY statements used with ESC, TAB, UP, DOWN, LEFT, RIGHT, HELP, NEXT, PREVIOUS, INSERT, CONTROL-M, CONTROL-X, CONTROL-V, CONTROL-C and CONTROL-A should be avoided for use in GUI programs, because it's very likely to clash with default accelerators defined in the Action Defaults.

By default, ON KEY actions are not decorated with a default button in the action frame (i.e. default action view). You can show the default button by configuring a text attribute with the Action Defaults.

ON DRAG* and ON DROP blocks

These interaction blocks are used to implement Drag & Drop in a DISPLAY ARRAY controlling a table or treeview.

For more details, see Drag and Drop description in this page.

ON APPEND block

Similarly to the ON INSERT control block, the ON APPEND trigger can be used to enable row creation during a DISPLAY ARRAY dialog. If this block is defined, the dialog will automatically create the append action. This action can be decorated, enabled and disabled as a regular action.

If the dialog defines an ON ACTION append interaction block and the ON APPEND block is used, the compiler will stop with error -8408.

When the user fires the append action, the dialog first execute the user code of the AFTER ROW block if defined. Then the dialog moves to the end of the list, and creates a new row after the last existing row. After creating the row, the dialog executes the user code of the ON APPEND block.

Understand that the dialog handles only row creation actions and navigation, you must program the record input with a regular INPUT statement, to let the end user enter data for the new created row. This is typically done with an INPUT binding explicitly array fields to the screen record fields. The new current row in the program array is identified with arr_curr(), and the current screen line in the form is defined by scr_line():

01 ...
02  DISPLAY ARRAY arr TO scr.*
03   ...
04   ON APPEND
05     INPUT arr[arr_curr()] FROM sr[(scr_line()].* ;
06     ...

Pay attention to the semi-colon ending the INPUT instruction, which is usually needed here to solve a language grammar conflict when nested dialog instructions are implemented.

After the user code is executed, the dialog gets the control back and processes the new row as follows:

• If the INT_FLAG global variable is FALSE and STATUS is zero, the new row is kept in the program array, and the BEFORE ROW block is executed for the new created row.
• If the INT_FLAG global variable is TRUE or STATUS is different from zero, the new row is removed from the program array, and the BEFORE ROW block is executed for the row that was existing at the current position, before the new row was created.

Note that the DISPLAY ARRAY dialog always resets INT_FLAG to FALSE and STATUS to zero before executing the user code of the ON APPEND block.

The append action is disabled if the maximum number of rows is reached.

ON INSERT block

Similarly to the ON APPEND control block, the ON INSERT trigger can be used to enable row creation during a DISPLAY ARRAY dialog. If this block is defined, the dialog will automatically create the insert action. This action can be decorated, enabled and disabled as a regular action.

If the dialog defines an ON ACTION insert interaction block and the ON INSERT block is used, the compiler will stop with error -8408.

When the user fires the insert action, the dialog first execute the user code of the AFTER ROW block if defined. Then the new row is created: The insert action creates a new row before current row in the list. After creating the row, the dialog executes the user code of the ON INSERT block.

Understand that the dialog handles only row creation actions and navigation, you must program the record input with a regular INPUT statement, to let the end user enter data for the new created row. This is typically done with an INPUT binding explicitly array fields to the screen record fields. The new current row in the program array is identified with arr_curr(), and the current screen line in the form is defined by scr_line():

01 ...
02  DISPLAY ARRAY arr TO scr.*
03   ...
04   ON INSERT
05     INPUT arr[arr_curr()] FROM sr[(scr_line()].* ;
06     ...

Pay attention to the semi-colon ending the INPUT instruction, which is usually needed here to solve a language grammar conflict when nested dialog instructions are implemented.

After the user code is executed, the dialog gets the control back and processes the new row as follows:

• If the INT_FLAG global variable is FALSE and STATUS is zero, the new row is kept in the program array, and the BEFORE ROW block is executed for the new created row.
• If the INT_FLAG global variable is TRUE or STATUS is different from zero, the new row is removed from the program array, and the BEFORE ROW block is executed for the row that was existing at the current position, before the new row was created.

Note that the DISPLAY ARRAY dialog always resets INT_FLAG to FALSE and STATUS to zero before executing the user code of the ON INSERT block.

The insert action is disabled if the maximum number of rows is reached.

ON UPDATE block

The ON UPDATE trigger can be used to enable row modification during a DISPLAY ARRAY dialog. If this block is defined, the dialog will automatically create the update action. This action can be decorated, enabled and disabled as regular actions.

You typically configure the TABLE container in the form by defining the DOUBLECLICK attribute to "update", in order to trigger the update action when the user double-clicks on a row.

If the dialog defines an ON ACTION update interaction block and the ON UPDATE block is used, the compiler will stop with error -8408.

When the user fires the update action, the dialog executes the user code of the ON UPDATE block.

Understand that the dialog handles only the row modification action and navigation, you must program the record input with a regular INPUT statement, to let the end user modify the data of the current row. This is typically done with an INPUT binding explicitly array fields to the screen record fields, with the WITHOUT DEFAULTS clause. The current row in the program array is identified with arr_curr(), and the current screen line in the form is defined by scr_line():

01 ...
02  DISPLAY ARRAY arr TO scr.*
03   ...
04   ON UPDATE
05     INPUT arr[arr_curr()] WITHOUT DEFAULTS FROM sr[scr_line()].* ;
06     ...

Pay attention to the semi-colon ending the INPUT instruction, which is usually needed here to solve a language grammar conflict when nested dialog instructions are implemented.

After the user code is executed, the dialog gets the control back and processes the current row as follows:

• If the INT_FLAG global variable is FALSE and STATUS is zero, the modified values of the current row are kept in the program array.
• If the INT_FLAG global variable is TRUE or STATUS is different from zero, the old values of the current row are restored in the program array.

Note that the DISPLAY ARRAY dialog always resets INT_FLAG to FALSE and STATUS to zero before executing the user code of the ON UPDATE block.

ON DELETE block

The ON DELETE trigger can be used to enable row deletion during a DISPLAY ARRAY dialog. If this block is defined, the dialog will automatically create the delete action. This action can be decorated, enabled and disabled as regular actions.

If the dialog defines an ON ACTION delete interaction block and the ON DELETE block is used, the compiler will stop with error -8408.

When the user fires the delete action, the dialog executes the user code of the ON DELETE block.

Understand that the dialog handles only the row deletion action and navigation, you can typically program a validation dialog box to let the user confirm the deletion. The current row in the program array is identified with arr_curr():

01 ...
02  DISPLAY ARRAY arr TO scr.*
03   ...
04   ON DELETE
05     IF fgl_winQuestion("Delete", "Do you want to delete this record?", "yes", "no|yes", "help", 0) == "no" THEN
06        LET int_flag = TRUE
07     END IF
08     ...

After the user code is executed, the dialog gets the control back and processes the current row as follows:

• If the INT_FLAG global variable is FALSE and STATUS is zero, the current row is deleted from the program array, and the BEFORE ROW block is executed for the next row in the list.
• If the INT_FLAG global variable is TRUE or STATUS is different from zero, the current row is kept in the program array, and the BEFORE ROW block is executed again for the current row.

Note that the DISPLAY ARRAY dialog always resets INT_FLAG to FALSE and STATUS to zero before executing the user code of the ON DELETE block.

Control Instructions

• CONTINUE DISPLAY instruction
• EXIT DISPLAY instruction
• ACCEPT DISPLAY instruction

Continuing the dialog: CONTINUE DISPLAY

CONTINUE DISPLAY skips all subsequent statements in the current control block and gives the control back to the dialog. This instruction is useful when program control is nested within multiple conditional statements, and you want to return the control to the dialog. Note that if this instruction is called in a control block that is not AFTER DISPLAY, further control blocks might be executed according to the context. Actually, CONTINUE DISPLAY just instructs the dialog to continue as if the code in the control block was terminated (i.e. it's a kind of GOTO end_of_control_block). However, when executed in AFTER DISPLAY, the focus returns to the current row in the list, giving the user another chance to browse and select a row. In this case the BEFORE ROW of the current row will be invoked.

Leaving the dialog: EXIT DISPLAY

You can use the EXIT DISPLAY to terminate the DISPLAY ARRAY instruction and resume the program execution at the instruction immediately following the DISPLAY ARRAY block.

Validating the dialog: ACCEPT DISPLAY

The ACCEPT DISPLAY instruction validates the DISPLAY ARRAY instruction and exits the DISPLAY ARRAY instruction. The AFTER DISPLAY control block will be executed. Statements after ACCEPT DISPLAY will not be executed.

Control Class

Inside the dialog instruction, the predefined keyword DIALOG represents the current dialog object. It can be used to execute methods provided in the DIALOG built-in class.

For example, you can enable or disable an action with the ui.Dialog.setActionActive() dialog method, or you can hide and show a default action view with ui.Dialog.setActionHidden():

01 ...
02   BEFORE DISPLAY
03     CALL DIALOG.setActionActive( "refresh", FALSE )

Control Functions

The language provides several built-in functions and operators to use in a DISPLAY ARRAY statement. You can use the following built-in functions to keep track of the relative states of the current row, the program array, and the screen array or to access the field buffers and keystroke buffers. These functions and operators are:

• ARR_CURR()
• FGL_SET_ARR_CURR()
• ARR_COUNT()
• SCR_LINE()
• SET_COUNT()

SCROLL

Purpose:

The SCROLL instruction moves data rows up or down in a screen array.

Syntax:

where field-list is :

{ field-name
| table-name.*
| table-name.field-name
| screen-array[line].*
| screen-array[line].field-name
| screen-record.*
| screen-record.field-name
} [,...]

Notes:

1. field-name is the identifier of a field of the current form.
2. table-name is the identifier of a database table of the current form.
3. screen-record is the identifier of a screen record of the current form.
4. screen-array is the name of the screen array used of the current form.
5. lines is an integer literal or variables that specifies how far (in lines) to scroll the display.

Usage:

The SCROLL instruction specifies vertical movements of displayed values in all or some of the fields of a screen array within the current form.

Examples

Example 1: Full list mode

Form definition file "custlist.per":

01 DATABASE stores
02
03 LAYOUT
04 TABLE
05 {
06  Id       Name         LastName
07 [f001    |f002        |f003        ]
08 [f001    |f002        |f003        ]
09 [f001    |f002        |f003        ]
10 [f001    |f002        |f003        ]
11 [f001    |f002        |f003        ]
12 [f001    |f002        |f003        ]
13 }
14 END
15 END
16 
17 TABLES
18 customer
19 END
20
21 ATTRIBUTES
22 f001 = customer.customer_num;
23 f002 = customer.fname;
24 f003 = customer.lname;
25 END
26
27 INSTRUCTIONS
28 DELIMITERS "||";
29 SCREEN RECORD srec[6] (
30        customer.customer_num,
31        customer.fname,
32        customer.lname);
33 END

Application:

01 MAIN
02   DEFINE cnt INTEGER
03   DEFINE arr ARRAY[500] OF RECORD
04             id INTEGER,
05             fname CHAR(30),
06             lname CHAR(30)
07         END RECORD 
08
09   DATABASE stores7
10   
11   OPEN FORM f1 FROM "custlist"
12   DISPLAY FORM f1
13
14   DECLARE c1 CURSOR FOR
15     SELECT customer_num, fname, lname FROM customer
16   LET cnt = 1
17   FOREACH c1 INTO arr[cnt].*
18     LET cnt = cnt + 1
19   END FOREACH
20   LET cnt = cnt - 1
21   DISPLAY ARRAY arr TO srec.* ATTRIBUTES(COUNT=cnt)
22     ON ACTION print
23        DISPLAY "Print a report"
24   END DISPLAY
25 END MAIN

Example 2: Paged mode

Form definition file "custlist.per" (same as example 1)

Application:

01 MAIN
02   DEFINE arr DYNAMIC ARRAY OF RECORD
03             id INTEGER,
04             fname CHAR(30),
05             lname CHAR(30)
06         END RECORD 
07   DEFINE cnt, ofs, len, row, i INTEGER
08
09   DATABASE stores7
10
11   OPEN FORM f1 FROM "custlist"
12   DISPLAY FORM f1
13
14   DECLARE c1 SCROLL CURSOR FOR
15          SELECT customer_num, fname, lname FROM customer
16   OPEN c1
17   DISPLAY ARRAY arr TO srec.* ATTRIBUTES(COUNT=-1)
18     ON FILL BUFFER
19        LET ofs = fgl_dialog_getBufferStart()
20        LET len = fgl_dialog_getBufferLength()
21        LET row = ofs
22        FOR i=1 TO len
23           FETCH ABSOLUTE row c1 INTO arr[i].*
24           IF SQLCA.SQLCODE!=0 THEN
25             CALL DIALOG.setArrayLength("srec",row-1)
26             EXIT FOR
27           END IF
28           LET row = row + 1
29        END FOR
30     AFTER DISPLAY
31        IF NOT int_flag THEN
32           DISPLAY "Selected customer is #"
33                   || arr[arr_curr()-ofs+1].id
34        END IF
35   END DISPLAY
36 END MAIN