DESIGNING FORMS [ HP Data Entry and Forms Management System (VPLUS/V) ] MPE/iX 5.0 Documentation
HP Data Entry and Forms Management System (VPLUS/V)
DESIGNING FORMS
FORMSPEC allows you to design forms in as simple or as complex a manner
as you desire. Whatever the level of complexity of the final forms,
designing the forms with FORMSPEC is easy and fast.
Forms are kept in a forms file, which must be compiled before the forms
can be used. There may be one or many forms in a forms file. In fact,
there may be multiple forms files per application or multiple
applications per forms file, depending on the complexity of the task to
be performed. Any form can be modified while you are initially designing
the forms, or you can modify forms after the forms file is compiled.
The form specifications are entered on formatted screens called "menus"
that are displayed by FORMSPEC. A combination of a Main Menu and terminal
function keys gives you complete control over display of the FORMSPEC
menus. You can thus change existing forms, add new forms, delete forms
or fields, and so forth.
Levels of Form Design
Form design with FORMSPEC can be thought of as having four levels of
complexity:
1. Simple Layout the form and allow any character set codes
Collection entered by the user. This level keeps the default field
attributes and does not require any other FORMSPEC
editing or formatting capabilities.
2. Simple Layout the form and specify edits for the field
Editing attributes, such as on field type (optional, required,
display only) or data type (character, numeric, or
date). No processing specifications are required for
the field attributes.
3. Full Field Specify field edits using those processing
Edits specifications that apply to individual fields in a
form. These include: minimum length, range checks,
pattern checks, and so forth. A subset of the available
processing specifications are used for these edits.
4. Advanced Specify movement of data between fields and forms,
Processing arithmetic computation of data, formatting of data
(JUSTIFY, FILL, STRIP), alteration of forms sequence,
and conditional processing based on the result of
processing specifications. This level uses the full
range of the processing specifications.
Simple Collection
When you run FORMSPEC, the first menu is the Forms File Menu where you
specify the name of the forms file. Then the Main Menu is displayed
where you can select what you want to do: add a form or a save field,
modify or delete a form, copy a form, select a terminal type or a native
language, compile the forms file, or go to the global characteristics or
to a particular form or field,
Suppose you want to add a form. FORMSPEC displays a Form Menu (see
Figure 1-2) on which you enter the form name and how you want the form to
be sequenced.
Figure 1-2. FORMSPEC Form Menu
Note that the sequence in which forms are displayed is very flexible. In
Sections 3 and 4 you will learn how to specify whether the current form
is to be repeated, or repeated and appended to itself. You not only
specify the name of the next form, but whether it is to replace the
current form or be appended to it, and if appended, whether the current
form is to be "frozen" on the screen when the next form is appended.
Next, FORMSPEC clears the screen so you can layout your form on a blank
screen. You can use any of the terminal capabilities to insert or delete
lines or characters, and to position the cursor. Refer to Figure 1-3 for
a sample form layout. The special terminal capabilities that provide
field enhancements such as "half bright", "color", "inverse video", or
"blinking" are entered through FORMSPEC, as described in Sections 3 and
4. You do not need to use complicated escape sequences to request them.
The position of a field is defined by field delimiters. You identify
each field by typing its name within these delimiters. This name can
later be changed to a longer identifier if desired (see Simple Editing
below). The maximum length of each field is defined automatically by
where you place the beginning and ending of the field. Field delimiters
can be either brackets ([]) or invisible control characters, as shown in
Figure 1-3.
Figure 1-3. FORMSPEC Screen Design
At this point, the form is completely designed at the simplest level.
Simple Editing
If you want to have more control over the data entered into a form, you
can use the Field Menus displayed by FORMSPEC for each field in a form.
Refer to Figure 1-4 for an illustration of a typical Field Menu, which
shows the various field attributes in the highlighted fields. The field
name and length determined by the form design are displayed on this menu.
The menu also displays the data type, field enhancements, and the field
type, any of which you can change by typing a new value over the
displayed value. You can also assign the field a new name by which it is
subsequently referenced, and you can specify an initial value for the
field.
Field Type. This attribute controls how data is entered in the field.
For example, if a field must contain a value, simply change the field
type from the default value, O for "optional", to R for "required". This
causes an error message to be issued if no data is entered in the field.
If you want to prevent the user from entering data in the field because
you plan to use it only to display data, change the field type to D for
"display only". You may force a field to be processed even if it is
blank by changing the field type to P for "process".
Figure 1-4. Sample Field Menu
Data Type. This attribute controls the type of data entered in the
field. Suppose you want to make sure that only digits are entered.
Simply change the data type from the default type (CHAR for any character
set code) to DIG. Or, if you want to allow entry of a signed number with
two decimal positions and a decimal point, you can change the data type
to NUM2. If a non-numeric value is entered, an error is diagnosed.
Field Name. An identifier for each field is typed within the field
during form design. Since this limits the field name to the length of
the field, you may want to assign a longer identifier on this menu.
Field Enhancement. Unless you change it on the Field Menu (or in the
Globals Menu), each field is displayed in half bright, inverse video
(code=HI). Other enhancements, underline) blinking, color, and security
(color and security are only supported on some terminals - refer to
"Supported Terminals Features" in Appendix G), can be combined with or
replace the default enhancements, or you can eliminate field enhancements
altogether.
Initial Value. You can specify in the Field Menu a particular value to
be displayed in that field when the form is first displayed at the
terminal.
The field type of the item PRICE in Figure 1-4 has been changed to R
(required), and its data type has been changed to NUM2. By making such
simple changes to Field Menus, a form with simple edits can be completely
designed.
Full Field Edits
To give you the capability to specify full field edits or advanced form
and field processing, FORMSPEC provides a simple language whose
statements you enter in the lower portion of the Field Menu, the area
labeled *Processing Specifications*. These field processing
specifications let you check a field value for:
Minimum Length The value entered must be at least a specified number of
characters long.
For example: MINLEN 10
means at least ten characters must be entered in the
field.
Equality The value entered must be equal to, equal to or greater
than, equal to or less than, less than, greater than, or
not equal to a specified value.
For example: GE FIELD2
means the value entered must be equal to or greater than
the value entered in a different field, FIELD2.
Range Check The value entered must be within (or not within) a range
of values.
For example: IN 10:20,F1:F4,100:300
means the value must be between 10 and 20, or between
the values entered in fields F1 and F4, or between 100
and 300, inclusive.
Table Check The value entered must be in (or not in) a table of
values.
For example: IN 5,10,15,F7+5
means the value must be 5, 10, 15, or the current value
of field F7 plus 5.
Pattern Check A check digit in the entered value is checked according
to modulus 10 or 11.
For example: CDIGIT 10
checks the value according to a modulus 10 check digit
test.
Any of these edits is performed immediately when data is entered in the
form.
Advanced Form Processing
In advanced processing, the sequence of specifications must be
considered. As such, these statements are similar to elements of a
programming language where the order in which they are entered is
significant. Figure 1-5 illustrates a Field Menu that includes advanced
processing specifications.
Figure 1-5. Advanced Processing Specifications
In this example, the UPRICE field (already specified as required and
numeric) is further limited. The minimum value that may be entered in
this field is 1. A custom error message "MINIMUM ORDER IS $1.00" will be
displayed if any value less than 1 is entered by the user. Further, if a
value greater than 10,000 is entered, a special next form, FORM2, will be
displayed when the user presses ENTER.
Advanced Processing Statements. The advanced processing statements
provide:
Data Movement Set any field to a particular value, or to a value moved
from another field. Default formatting of the data is
performed during movement according to the data type of
the destination field.
For example: SET TO !JUNE 17,1986!
moves the date constant (delimited by exclamation
points) to the current field.
Another example: SET F1 TO F3
moves the value in the field F3 to the field F1.
Arithmetic Set any numeric field to a value calculated using
Calculation standard arithmetic operators (+, -, *, /, %).
For example: SET TAX TO TOTAL*TAX_RATE
multiplies the value in the field TOTAL by the value in
the field TAX_RATE and moves the result to the field
TAX. (All these fields must be numeric.)
Data Formatting In addition to default formatting, you can specify
particular formatting of the entered data. Formatting
includes: STRIP, JUSTIFY, FILL and UPSHIFT.
For example: JUSTIFY RIGHT; FILL LEADING "0"
moves the data to the right of the field, and then fills
any leading blanks with zeros.
Forms Change the form sequence originally specified for the
Sequencing form on the Form Menu.
For example: CHANGE NFORM TO $HEAD
changes the next form to the head form. The head form
is the first form displayed.
Another example: CHANGE CFORM TO NO REPEAT
stops the current form from repeating.
Conditionals Execute a processing specification, or group of
specifications, only if a particular edit is true.
For example: IF F1 EQ 20 CHANGE NFORM TO CLEAR
clears the current form and displays the next form when
the value of field F1 equals 20.
Phases Executes processing statements in one of four phases:
configuration CONFIG, initialization INIT, field editing
FIELD, and finish FINISH.
Save Fields & Other Global Specifications. Special fields, called "save
fields", can be defined for the entire forms file. These fields are
global to the forms file, and can be referenced in the processing
specifications of any field in any form. Save fields are useful
primarily in order to pass values between forms. They are defined on a
special menu, the Save Field Menu.
Certain global characteristics of a form, such as default field or error
enhancements, and the placement of the error/status line on the form are
supplied by FORMSPEC as defaults. You may change these default
characteristics through the Globals Menu.
Application-Ready Buffer
An Application-Ready buffer (ARB) is a buffer passed between the
application and the run-time intrinsics for data collection and display.
It has these features:
* It stores data as the application will use it, which may differ from
the way it appears on the screen.
* It is synchronized with other application sources, such as the
program code and databases.
* It facilitates maintenance in that the user can rearrange fields on
the screen without needing to modify the application program.
Conversely, changes to the database affect the ARB, but not
necessarily the screen.
* It supports an extended range of data types, including floating-point
decimal land COBOL packed and zoned decimal.
* It simplifies coding because calls to VGETtype and VPUTtype are no
longer needed: one call to VGET/PUTBUFFER is sufficient.
The Application-Ready Buffer presents data as the application expects to
use it, for example, to update a database, whereas the screen receives
and displays data in the format that makes best sense to the user. The
distinction between screen data and application-ready data facilitates
maintenance and provides a mechanism for integrating FORMSPEC with a data
dictionary if desired. If the definition of a database element changes,
the ARB must be changed accordingly, but no change need necessarily be
made to the screen. The designer can also change the screen layout, by
altering the order of fields, for example, without having to modify the
application source code.
The application receives the ARB from a VPLUS/V VGETBUFFER or sends it to
the screen via VPUTBUFFER. The ARB returned to the application contains
the data that the user entered, now transformed according to the
designer's specifications. These may include adding, deleting and
rearranging fields, as well as transforming and replacing data. A mode
flag in the VPLUS comarea indicates whether the data is to be transformed
or left "raw". As input to VPUTBUFFER, the ARB contains the information
the application wishes to display on the user's screen.
Benefits of the ARB. The Application-Ready Buffer greatly simplifies
screen/application data conversions. Previously, application programmers
had to call VGET/PUTtype for each field that needed to be converted in a
given transaction (or had to write code to perform conversions). Now
they need only specify a default conversion for each screen and ARB data
type, request automatic generation of the ARB from the form, and make any
modifications that may be necessary for a particular field. This should
considerably simplify the code, making it easier to read and maintain,
and transaction response time should be unaffected.
The creation of an ARB is described in detail in Section 3.
MPE/iX 5.0 Documentation