Forms 
|
| Forms | | Screens |
A screen in this sense is not necessarily a display which fits on one window. A screen can be broken up into pages which do correspond to a single window. If more lines are specified on a screen than fit on the window, then the screen will be displayed in pages or pages can be defined explicitly. Screens do not scroll.
The sequence of the commands within the screen definition determines the order in which the cursor moves and the sequence in which the commands are executed (the "flow of control"). If screen positioning clauses are used, this may not necessarily be the "natural" order of fields as they appear on the screen.
The command names the screen and screen names must be unique within a form.
The set of commands for a screen must end with the appropriate END
command; ENDMENU, ENDRECORD or ENDTABLE.
The main difference between the screens defined by RECORD,
TABLE
and MENU commands is that record screens access data
from a single record in a database whereas table screens access data from a
single row in a table. Menu screens do not access any external data.
All screen types have access to any temporary variables defined in the form.
The syntax
for the commands is the same except that
AUTOWRITE only applies to RECORD and
TABLE screens.
| |
MENU screennameA menu screen starts with the
MENU command followed by the screen
name and finishes with
ENDMENU. Within a menu screen, other commands can
be used, however FIELD commands can only refer to
temporary variables not to database or table variables.Menu screens may consist simply of choices as to which screens to go to or a menu can be a complete data entry screen providing that it only refers to temporary variables. These can then be passed to record or table screen to write the data.
See syntax.
| |
RECORD screenname [/database.record]A record screen starts with the
RECORD command and ends with
ENDRECORD.
Specify the command RECORD followed by the name of the screen
and, optionally, the name of the record and the name of the database. If a
record name is not specified, the screen name must be the record name. If a
database name is not specified, the first database defined on the
FORM command is the default.
The same record type can be associated with multiple screen definitions in the same form definition to allow different ways of viewing the same data. Each screen name must be unique.
Record screens access and display one record at a time. Once
control has been passed to a record screen, a record can be
retrieved or a new entry created. The user can enter the key fields to
locate the record, or can find the appropriate record or row with
commands such as FIRST, LAST, NEXT or
PREVIOUS. If the record or set of records to be retrieved has
been determined in a previous screen, this information can be passed down with
the CALL command.
Within a screen, commands can reference any variable from that record plus any temporary variables. Commands can also reference variables from the CIR on record screens in a case structured database.
See syntax.
| |
TABLE screenname [/tabfile.table] [ INDEXED BY indexname ]A table screen starts with the
TABLE command and ends with
ENDTABLE.
Specify the command TABLE followed by the name of the screen
and, optionally, the name of the table and the name of the tabfile. If a table
is not specified on the TABLE command, the screen name must be
the table name. If a tabfile is not specified, the default tabfile is the first
tabfile defined on the FORM command.
An index can be specified for a table and the index variables are treated as the
key fields. The index variables must appear first on the screen. Only one index
can be specified for a table screen. If an index is not specified, the default
access mode is Search and the table is processed sequentially.
The same table can be associated with multiple screen definitions in the same form definition to allow different ways of viewing the same data. Each screen name must be unique.
Table screens access and display one row at a time. Once
control has been passed to a table screen, a row can be
retrieved or a new entry created. The user can enter the key fields to
locate the row, or can find the appropriate row with
commands such as FIRST, LAST, NEXT or
PREVIOUS. If the row or set of rows to be retrieved has
been determined in a previous screen, this information can be passed down with
the CALL command.
Within a screen, commands can reference any variable from that table plus any temporary variables.
See syntax.
| |
RECORD, TABLE and MENU commands are:
(condition) 'error message',[OPTIONAL] ...(condition) 'error message',[OPTIONAL] ... variable=expression, ... variable=expression, ...variable, ...name ACTIVITIES permissionsACTIVITIES permissionsAT [ r ] [, c ][NO]AUTOTABBOTTOM nCLEAR 'c'DATA HILITE | VIDEO optionsERROR number [ VIDEO options ] 'error text' , ....PAD [n][,m]PAGESIZE [r][,c]PROMPT HILITE | VIDEO options
| |
ACCEPT (condition) 'error message' , ... [ OPTIONAL ]ACCEPT specifies one or more checks to be performed before the
user "moves away" from a screen. Moving away from a screen means retrieving
a new record on this screen, calling another screen or returning to the screen
that called this one.
If an ACCEPT expression is not true, the specified message is
displayed and the cursor returns to the first input field. If a message is not
specified, a default message is used. If both ACCEPT and
REJECT are specified, the ACCEPT is actioned
first and records must meet all specified criteria in order to be accepted.
Only one ACCEPT clause can be specified on a command.
Specify the keyword OPTIONAL after all conditions to allow the
user to override the warning. OPTIONAL applies to all the
specified conditions.
Specify the BOOLEAN clause on the FIELD
command to test individual fields. This is the preferred practice for testing
individual fields since the cursor is then positioned on the field in error.
Example: To leave the screen only when
DATE2 is equal to or greater than DATE1
specify:
ACCEPT (DATE2 GE DATE1) 'Invalid dates .. Please re-enter'
| |
[NO]AUTO WRITEAUTO WRITE specifies that a new record is written when the
user moves away from the screen. If NOAUTO WRITE is
specified, a prompt is issued for permission to write the record.
If the user issues an explicit WRITE command, the setting
of AUTO WRITE has no effect.
Moving away from a screen means retrieving a new record on this screen, calling another screen or returning to the screen that called this one.
| |
FINAL COMPUTE variable = expression, ...
IF (expression) variable = expression, ...
Specifies computations which are done when the user moves away from a
screen. Moving away from a screen means retrieving a new record on this screen,
calling another screen or returning to the screen that called this one.
Regardless of the number of variables to be computed, only specify the keyword
FINAL once. The computations are performed before any
ACCEPT or REJECT.
Variables can be computed with COMPUTE or conditionally
computed using IF. Multiple COMPUTE and
IF statements can be specified. Use a comma to separate
expressions. An expression can be enclosed in parentheses.
Example: To compute the sum of VAR1, VAR2
and VAR3 on exit from the screen, specify:
FINAL COMPUTE TOTAL = VAR1 + VAR2 + VAR3
| |
INITIAL COMPUTE variable = expression, ...
IF (expression) variable = expression, ...
Specifies computations which are done when the user first moves to the
screen. Regardless of the number of variables to be computed, only specify the
keyword INITIAL once. The INITIAL
computations are performed before the first command in the screen and before a
record or row is accessed.
Variables can be computed using COMPUTE or conditionally
computed using IF. Multiple COMPUTE and
IF statements can be specified. Use a comma to separate
expressions. An expression can be enclosed in parentheses.
Example: To set the global variable TIME
to the current time when a screen is accessed, specify:
INITIAL COMPUTE TIME=NOW(0)
| |
NUMSCR parameter on the execution statement.
| |
| |
RECEIVING variable, ...PASSING
clause on the CALL statement in the calling screen. The
variables in the Passing/Receiving list are matched by position. That is, the
first variable in the passing list corresponds to the first variable in the
receiving list, the second variable in the passing list corresponds to the
second variable in the receiving list, etc.
Values that are "received" are DISPLAY fields and cannot be
modified.
When creating a new record, RECEIVING forces a value into the
variable. If an existing record is retrieved, all the record variables are set
to the values from the database. This means that received data is overwritten
and the only effect is to make the variable a DISPLAY field.
A screen may be called from more than one place. If a CALL
does not pass any data, RECEIVING has no effect.
| |
REJECT (condition) 'error message', ... [ OPTIONAL]
If a REJECT expression is true, the specified message is
displayed and the cursor returns to the first input field. If a message is not
specified, a default message is used. If both ACCEPT and
REJECT are specified, the ACCEPT is actioned
first and records must meet all specified criteria in order to be accepted.
Only one REJECT clause can be specified on a command.
Specify the keyword OPTIONAL after all conditions to allow the
user to override the warning. OPTIONAL applies to all the
specified conditions.
The BOOLEAN clause on the FIELD command can
be used to test individual fields. This is the preferred practice for testing
individual fields since the cursor is then positioned on the field in error.
Example: To stay on this screen and not move away when
DATE2 is equal to or greater than DATE1
specify:
REJECT (DATE2 GE DATE1) 'Invalid dates .. Please re-enter'
| |
STOPSCREENSTOP command
passes control back through any number of levels of calls to a stop screen.
Multiple stop screens can be specified. A user can skip back over a series
of screens instead of using the RETURN command in each screen.
The root screen is a stop screen by default.
| |
USERS GROUP name ACTIVITIES permissions
Regardless of how many groups are defined, only specify the keyword
USERS once. The keyword GROUP is followed by
the name of the group allowed to access the screen and the permissions allowed.
To restrict activities on this screen for everyone regardless of the group, omit
the keyword GROUP and the groupname. This specifies that all
groups are allowed access to the screen to perform the given permissions. If
USERS are specified for a screen, specify all groups that are
permitted access to the screen; any groups omitted from the
USERS clause are allowed no activities. The
ACTIVITIES clause specifies the permissions for the group.
(See activities for permissions).
If a USERS clause is specified on a screen, then for a group
to be allowed to perform an activity:
USERS GROUP must be specified at the
FORM level and the activity must be allowed. This allows
access to the Form and to that activity in general.
USERS GROUP on
this screen.
ACTIVITIES are specified for the screen, the
activity must be specified.
Example: Allow only group LOOK to access
the Menu screen SUBMENU.
MENU SUBMENU USERS GROUP LOOK
| |