HP 3000 Manuals

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.

	       Click here to view figure.
          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.

	       Click here to view figure.
          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".

	       Click here to view figure.
          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.

	       Click here to view figure.
          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