Defining the Form

Screen Arrays

In a text-based form specification file (.per), a screen array is usually a repetitive array of fields in the LAYOUT section, each containing identical groups of screen fields.

Each "row" of a screen array is a screen record. Each "column" of a screen array consists of fields with the same item tag in the LAYOUT section of the form specification file. You must declare screen arrays in the INSTRUCTIONSsection.

TABLE Containers

The TABLE container in a form defines the presentation of a list of records, bound to a screen array.

When this layout container is used with curly braces defining the container area, the position of the static labels and item tags is automatically detected by the form compiler to build a graphical object displaying a list of records.

The first line of the TABLE area contains text entries defining the column titles. The second line contains field item tags that define the columns of the table receiving the data. This line is repeated to allow the display of multiple records at once.

The user can sort the rows displayed in the form table by a mouse-click on the title of the column that is to be used for the sort. This sort is performed on the client side only. The columns and the entire form can be stretched and re-sized. A right-mouse-click on a column title displays a dropdown list-box of column names, with radio buttons allowing the user to indicate whether a specific column is to be hidden or shown.

The INSTRUCTIONS section

You must declare a screen array in the INSTRUCTIONS section of a text-based form specification file (.per) with the SCREEN RECORD keyword. You can reference the names of the screen array in the DISPLAY ARRAY statement of the program.

Form example: manycust.per

The manycust.per form specification file contains a TABLE Container and screen array used to display a list of customer rows

Form manycust.per:

01 SCHEMA custdemo 
02
03 LAYOUT
04  TABLE
05  {
06   Id   Name           ...   zip_code   Contact          Phone 
07  [f01][f02           ]     [f05     ][f06            ][f07         ]
08  [f01][f02           ]     [f05     ][f06            ][f07         ]
09  [f01][f02           ]     [f05     ][f06            ][f07         ]
10  [f01][f02           ]     [f05     ][f06            ][f07         ]
11  [f01][f02           ]     [f05     ][f06            ][f07         ]
12  [f01][f02           ]     [f05     ][f06            ][f07         ]
13  }
14  END
15 END
16
17 TABLES 
18   customer 
19 END
20
21 ATTRIBUTES
22 EDIT f01=customer.store_num;
23 EDIT f02=customer.store_name;
24 EDIT f03=customer.city;
25 EDIT f04=customer.state;
26 EDIT f05=customer.zip_code;
27 EDIT f06=customer.contact_name;
28 EDIT f07=customer.phone;
29 END
30
31 INSTRUCTIONS
32 SCREEN RECORD sa_cust (customer.*);
33 END

Note:

In order to fit on the page, the layout section of the form is truncated, not displaying the city and state columns.

Line 01 The custdemo schema will be used by the compiler to determine the data types of the form fields.
Line 06 contains the titles for the columns in the TABLE.
Lines 07 thru 12 define the display area for the screen records. These rows must be identical in a TABLE. (The fields for city and state are indicated by .... so the layout will fit on this page.)
Line 21 thru 29 In the ATTRIBUTES section the field item tags are linked to the field description. Although there are multiple occurrences of each item tags in the form, the description is listed only once for each unique field item tag.
Line 32 defines the screen array in the INSTRUCTIONS section. The screen record must contain the same number of elements as the records in the TABLE container. This example defines the screen record with all fields defined with the customerprefix, but you can list each field name individually.