EASE OF FORMS DESIGN

Once you have specified a forms file and the Main Menu is displayed, you are ready to use FORMSPEC to create forms. Whenever you create a new forms file, your first task is always to add a form; if you are modifying an existing file, you may want to add a form. In either case, you follow the sequence of menus shown in Figure 3-4 “Sequence of Menus for Form Design” Refer to the menu descriptions later in this section for more information on all the FORMSPEC menus.

Figure 3-4 Sequence of Menus for Form Design

A Form Menu, shown later in Figure 3-10 “Example of a Form Menu”, allows you to define the characteristics of each form, such as the form name and what form sequencing options to use. Refer to "Understanding Form Sequencing" below.

Form Layout

The Form Menu is followed by a blank screen on which you design the layout of the form as it will appear on the screen. An example of a form layout is shown in Figure 3-5 “Example of a Form Layout” This layout is easy to draw on the screen — and easy to change at this stage or later. You use your terminal editing keys to layout the fields and text of your form on the screen; refer to your terminal manual for more information.

Figure 3-5 Example of a Form Layout

Each layout consists of two kinds of information:

Fields: Areas, delimited on the form, into which data will be entered by or displayed to the user. The maximum number of fields allowed on anyone form is 128.
Text: The headings and other displayed information that appears on the form but is never altered during execution.

You must distinguish between these two kinds of information within the form layout using field delimiters and field tags to indicate the fields.

Field Delimiters

The data fields are delimited by brackets ( [ ] ), by ESCAPE followed by brackets, or by a combination of these. Pressing ESCAPE, then bracket, prevents the brackets from being displayed on the screen.

Printed Delimiters. If you delimit the data fields with brackets, they are not included in the length of the field, but they do take on the display enhancements assigned to the field. Brackets make it easy to see where a field begins and ends during definition, but they take up space on the form. If you must concatenate two data fields, you should use nonprinting delimiters to delimit the fields.

Nonprinting Delimiters. You can also delimit fields by pressing ESCAPE followed by:

the left bracket ( [ ) OR the right bracket ( ] ).

The advantage of these delimiters is that they take up no space on the form and thus can be used to delimit contiguous fields. The disadvantage of using these keys is that they are not displayed and therefore do not show up during form design.

Mixing Printing and Nonprinting Delimiters. To use one printing and one nonprinting delimiter to fix the boundaries of a field, use the delimiters as follows:

If the printing delimiter is to come first, use

[ ESCAPE [fieldtag. . . ESCAPE ]

If the printing delimiter is to come last, use

ESCAPE [fieldtag. . .ESCAPE ]

In the case where a field begins with ESCAPE [ and ends with ], the terminal will insert ESCAPE ] if a following field also starts with ESCAPE [. As a result VPLUS will reject the form layout. This terminal feature can be avoided by properly using the above rules for mixing delimiters. Refer to Figure 3-6 “Examples of Form Layouts” for examples of different ways to layout a form.

Figure 3-6 Examples of Form Layouts

Field Tag

Regardless of the technique used to delimit the fields, each field must be identified by a "field tag". This tag consists of (USASCII only) letters of the alphabet (uppercase or lowercase), digits, or the underline (). The first character must be alphabetic. Since the field tag must be specified within the field delimiters, it is limited to a length less than or equal to the number of characters in the field. Thus, if you have a one-character field, its tag may not have more than one character. However, the field tag is also used for the field name. You may change any field name on the Field Menu. Thus, you can give a one-character tag a longer field name when the Field Menu for the field is displayed.

Note that for the field tag, uppercase letters differ from lowercase letters. Thus, f1 and F1 are two different tags. All other names used by FORMSPEC make no distinction between uppercase and lowercase letters, but shift all letters to uppercase. Since each tag is upshifted when used as the default field name, tags that differ on the form may result in identical field names. When this occurs, you must rename one of the identical field names on a Field Menu. Each field tag must be unique before it is upshifted, thus, a form may have up to 52 one-character fields.

You can fill up the field with dots (periods). This gives you a visual representation of field size while you are designing the field. Using dots in the field is particularly useful when the field is delimited by ESCAPE [ and ESCAPE ] since these delimiters are not displayed. The dots do not show up when the form is displayed by the application.

Defining the Fields

After defining the form layout, FORMSPEC displays a Field Menu for each field, such as the example shown in Figure 3-7 “Example of a Field Menu”

Figure 3-7 Example of a Field Menu

Each Field Menu displays the portion of the form containing the current field. Compare Figure 3-5 “Example of a Form Layout” and Figure 3-7 “Example of a Field Menu”; notice the portion of the form layout of Figure 3-7 “Example of a Field Menu” that is displayed in the Field Menu in Figure 3-5 “Example of a Form Layout” The current field is indicated by a caret (^) under the field tag. In the example in Figure 3-7 “Example of a Field Menu”, the current field is labeled Date: with the field tag of ordate.

The information you enter on the Field Menu is divided into two categories: field attributes and processing specifications. The field attributes are the two lines of fields below the portion containing the current field. For example:

Figure 3-8 The Field Attributes

Only the field attributes are discussed here. The processing specifications are described in Section 4. If you can use the field attributes without change, the entire form design is complete at this point. If not, you can specify any simple edits, as described below, or, if you want to use the FORMSPEC processing specifications, described in Section 4, you can enter appropriate processing specifications on the Field Menu. As shown in Figure 3-4 “Sequence of Menus for Form Design”, the form design sequence can be repeated until all forms in the file are defined.

Field Number

Although your form may have a maximum of 128 fields, a number between one and 256 is assigned by FORMSPEC to each new field. This number is assigned to the field and is not changed even if other field characteristics are changed. If, however, the field tag is changed, this effectively deletes the field associated with the old tag. The field number is deleted along with the field, and a new number is assigned to the field associated with the new tag. The field numbers of a form can be renumbered in screen order with the FORMSPEC batch mode command RENUMBER, as described in Section 7.

Field Length

This is the length of the field as determined by the number of characters entered between the field delimiters during form layout. The length of a field cannot be changed on the Field Menu. If you want to change field length, you must display the form layout and actually change the field on the form. If you change the field length on the form, the new length is automatically reflected in the Field Menus.

If you want to design a field that is longer than one line, you start the field with a bracket (or ESCAPE[) and terminate it with a closing bracket (or ESCAPE ]). At the beginning of each intermediate line of the field, you enter an ESCAPE [.

For example, as shown in Figure 3-9 “Example of a Field Extending over Several Lines”, consider a field that extends across three lines.

Figure 3-9 Example of a Field Extending over Several Lines

Assuming the first line of the field contains 79 characters, the second line contains 80 characters, and the third line contains 34 characters, the entire field is 193 characters long. This count excludes the printing brackets which delimit the beginning and the end of the field.

Field Name

The field tag assigned during form design is shifted up to all uppercase letters and becomes the field name. You can enter another name in this field. For example, you may want a longer name than would fit in the field, or if two tags are no longer unique when shifted to all capitals, you can rename one of them here. In any case, the name in this field (an upshifted tag or a new name) identifies the field in subsequent references. It must not be one of the reserved words listed in Table 3-2 “FORMSPEC Reserved Word List”

Table 3-2 FORMSPEC Reserved Word List

ALL	FILL	LOCALEDITS	SET
APPEND	FINISH	LT	STDCHAR
BARCODE	FREEZE	MAGSTRIPE	STOP
CAD	GE	MARKS	STRIP
CDIGIT	GT	MAT	THEN
CENTER	HOLES	MATCH	TO
CFORM	IF	MFR	TRAILING
CHANGE	ILV	MINLEN	TYPEV
CLEAR	IN	NE	UPC
COD	INIT	NFORM	UPSHIFT
CONFIG	125	NIN	$EMPTY
CUT	139	NOCUT	$END
DEVICE	JUSTIFY	NONE	$HEAD
DISPLAY	KEYBOARD	NOREPEAT	$LENGTH
EAN	LARGECHAR	OF	$REFRESH
ELSE	LE	PRINTER	$RETURN
EQ	LEADING	RELAY	$STATE
FAIL	LEFT	REPEAT	$TODAY
FIELD	LIGHT	RIGHT

You can enter any name up to 15 characters long. Like other FORMSPEC names, it must be USASCII and start with an alphabetic character. It may be followed by uppercase or lowercase letters (A-Z), numbers (0-9), or an underline ().

Default The uppercase field tag.

Display Enhancement

You can change the enhancement for the particular field with any combination of the codes shown in Figure 3-3 “Relation between Menus and Function Keys” Up to four of the available enhancements may be used at one time. The data capture devices do not support display enhancements.

Table 3-3 Display Enhancement

Enhancement	Code
Half Bright	H
Inverse video	I
Underline	U
Blinking	B
Security	S *
Color	1-8 *
None	NONE

Security and color enhancements are only available on terminals with the security or color feature, as listed in Appendix G. Refer to "Using Terminal Features" for more information on security and color.

Field Type

The field type is specified as D, R, O, or P to indicate one of the following options:

Display(D)

Field cannot be modified by the user. Intended for display only, the field can receive data as specified by processing specifications (see Section 4). It is a protected field on the form, but data is written to display only fields exactly as if it had been entered by the user.

Required(R)

Field cannot be left blank. User must enter nonblank values in field.

Optional(O)

Field may be left blank by user. Edit checks and field phase processing specifications for the field are skipped if the field is left blank.

Process(P)

Exactly like an optional field, except that edit checks are performed and field phase processing specifications are executed even if the field is blank.

Default O (optional)

Required, optional, and process fields are treated as "input" fields. An input field is one in which the user can enter or change data, as opposed to a display only field which is protected from user input. Note that initial values may be displayed in any field, but such values can be, and usually will be, changed by the user.

Data Type

There are two sets of data types, the screen data types and the ARB data types. If you are creating an ARB for a form, the application needs to know the ARB data types. Each field on the form and the ARB must be specified as one of three data types: character, numeric, or date. Based on the data type, FORMSPEC can determine the basic validity of the data entered, how it is formatted for data movement, and the type of operations that can be performed on the field.

Screen data types impose format and edit rules for data entered on the screen. ARB data types determine how that data will be interpreted by the application. Conversions from screen data type to ARB data type and vice versa occur automatically at runtime (see VGET/PUTBUFFER in section 7).

Screen Data Type. Valid screen data types are: CHAR, NUM(n), DIG, IMPn, MDY, DMY, and YMD.

Figure 3-4 “Sequence of Menus for Form Design” illustrates how each numeric data type interprets an entered value on the screen. The data types are described in the following paragraphs.

Default CHAR

Character Type. CHAR

Data entered in the field is assumed to be a string of any characters. No validity checking is performed on data at time of entry. No arithmetic operations can be performed on data of this type. The user can enter any characters in a CHAR type field. (As noted above, CHAR is the default data type.)

For example, $12.59, A-15-75, and **123** are all legitimate entries.

Numeric Types. NUM[n]

Data entered in a field of this type must be numeric. The maximum number of decimal places can be indicated by the optional digit, n, where n is a value between 0 and 9. If you omit the value, n, the data item is assumed to have a floating decimal point.

Validity checking is performed on this data type. An optional leading sign (+ or -) is allowed. Commas are allowed, but if included they must be correctly placed. An optional decimal point may be included in the data. When Native Language Support is used, the symbols used to indicate thousands and decimals are language-dependent. For more information on Native Language Support, see Section 8.

The user must enter numeric data in this field. If n specifies a maximum number of decimal positions, the user must include a decimal point when the value has decimal places, and may omit the decimal point when it does not.

For example, in a NUM2 field, the user can enter a value with no decimal places (such as 500) or a value with one decimal place (such as 5.5) or a value with two decimal places (such as 5.95). Commas and a sign may also be included. For example, the following are legitimate entries for a NUM2 field: 1,390, -327.00, +100,000.00 and so forth; but the value 5.678 is disallowed as it has too many decimal places.

DIG

Data entered in a field of this type must be a positive integer. No sign, no commas, and no decimal point can be included. As with NUM data, validity checks are performed on this data type.

For example, 10030, 2 and 307 are all legitimate entries in a DIG field, but 10.5, 100,000 or -10 are not.

IMP n

A value entered in an IMP field has an assumed decimal point. The assumed decimal point is n places from the right of the value. (Note that the value, n, must be specified.) Although permitted, a decimal point should not be entered in this type field, but commas and an optional leading sign (+ or -) are allowed. As with NUM type data, validity checks are performed on data of this type.

For example, if the data type is IMP2, and the user enters the value 500, the value is treated as 5.00.

With Native Language Support, the symbols accepted for thousands and accepted or required for decimal indication are language dependent. For more information on Native Language Support, see Section 8.

Table 3-4 How Each Numeric Data Type Interprets Entered Values

Entered Value	Interpreted Value (Based on data type)
Entered Value	NUM2	IMP2	NUM	NUM0	DIG
10.95	10.95	10.95	10.95	(error)	(error)
1095	1095.00	10.95	1095	1095	1095
10.9	10.90	10.90	10.9	(error)	(error)
10.956	(error)	(error)	10.956	(error)	(error)
-100	-100.00	-1.00	-100	-100	(error)
1,000	1,000.00	(error)	1,000	1,000	(error)
1,00000	(error)	1,000.00	(error)	(error)	(error)

Date Types.

MDY: A date entered in an MDY field must be in the order: month, day, year. The data can be entered in any format, such as FEB 6, 1986 or 02/06/86 or FEBRUARY 6 86 and so forth.
DMY: A date entered in a DMY field must be in the order: day, month, year. It can be any format, such as 2 MAR 1986 or 02-03-86 or 2/3/86 and so forth.
YMD: A date entered in a YMD field must be in the order: year, month, day. It can be in any format such as 1986, APRIL 12 or 86/4/12 or 86-04-1 or 860402.

The entered data is checked by VPLUS for correct format and that it is a valid date. Arithmetic operations are not allowed on date fields.

Native Language Support does not affect the order of the date field. It does, however, accept the names of months and their abbreviations for each native language at run-time. For more information on Native Language Support, see Section 8.

To illustrate how the three date type specifications interpret entered dates for NATIVE-3000, Figure 3-5 “Example of a Form Layout” shows legal dates followed by Figure 3-6 “Examples of Form Layouts” with dates that would be diagnosed as illegal.

Table 3-5 Valid Dates

MDY	DMY	YMD
`February 7, 1986`	`7 February 1986`	`1986, February 7`
`FEB 7 1986`	`7 FEB 1986`	`1986 FEB 7`
`02/07/86`	`07/02/86`	`86/02/07`
`2/7/86`	`7/2/86`	`86/2/7`
`02-7-86`	`07-2-86`	`86-2-07`
`2 7 86`	`7286`	`8627`
`020786`	`070286`	`860207`

Table 3-6 Invalid Dates

MDY	DMY	YMD	Reason
`Febrary 7, 1986`	`7 Febrary 1986`	`1986, Febrary 7`	Misspelled
`FEBR 7 1986`	`7 FEBR 1986`	`1986 FEBR 7`	Four letter abbreviation
`2786`	`7286`	`8627`	Must be a two-digit month, day when no separator is included.

ARB Data Types

The valid choices for ARB data types are: CHAR, INT, DINT, REAL, LONG, SPACKn, PACKn, SZONEn, ZONEn, and YYMMDD. Data type and length may differ from screen to ARB. The ARB data types include some that are language-specific. For example, SPACKn and PACKn correspond to COBOL COMP-3; SZONEn and ZONEn correspond to COBOL signed display numeric and unsigned display numeric respectively; and INT and DINT correspond to COBOL COMP. For more information on COBOL data types, see the COBOLII/3000 Reference Manual. The default data type and length for an ARB field are derived from the data type and length of the corresponding field on the associated form and the Data Type Conversion record.

Figure 3-7 “Example of a Field Menu” sets out recommended guidelines for data type conversions from screen to ARB and back.

Table 3-7 Recommended Data Type Conversions

Screen Data Type — >	ARB Data Type
`CHAR`	`CHAR` only
`YMD, DMY, MDY`	`YYMMDD, CHAR`
`DIG`	any except `YYMMDD, CHAR`
`NUM[n], IMPn`	any except `YYMMDD, CHAR`; "n" truncated if `INT, DINT`
ARB DATA Type — >	Screen Data Type
`CHAR`	`CHAR` only
`YYMMDD`	`MDY, YMD, DMY, CHAR, DIG`
`INT, DINT`	`DIG, NUM[n], IMPn;` positive only if `DIG`
`REAL, LONG, PACK, ZONE`	`DIG, NUM[n], IMPn;` if `DIG` - "n" truncated, positive only

FORMSPEC will ensure the following length specifications for ARB data types:

    YYMMDD length = 6
    INT    length = 2
    DINT   length = 4
    REAL   length = 4
    LONG   length = 8

YYMMDD is defined as a 6-byte ASCII field containing numeric data with no separators, in YMD order; for example, 860419.

The designer is responsible for making legitimate data conversions. The three critical factors are data type, value, and length. The following examples illustrate their importance.

Data Type: Runtime errors may arise from specifying a CHAR/DATE source conversion to a numeric destination, or a CHAR source to a DATE destination.
Value: The ARB data type INT may have a screen type of CHAR. This works if the field is for display only, but if it is an entry field, the user could input ABC unless the designer has taken steps to prevent it.
Length: Data may be truncated if the screen data type DIG is specified for a field of length 10 and the ARB type is INT (length 2 bytes, equal to 1 HP 3000 word). Both COBOL and Pascal can store numbers in the range -32768 to 32767 in one word.




	NOTE: These are recommendations only, and are not enforced by FORMSPEC edits. The programmer may set up the application code to handle non-standard conversions.

Figure 3-8 “The Field Attributes” shows the valid screen data types and their corresponding values for COBOL, Pascal and FORTRAN.

Table 3-8 Valid Screen Data Types

ARB Data Type	COBOL	Pascal	FORTRAN
`CHAR`	`PIC X (_)`	`Packed array CHAR [.._]`	`CHAR`
`YMD`	as above	as above	as above
`DMY`	as above	as above	as above
`DIG`	as above	as above	as above
`NUM[n]`	as above	as above	as above
`IMP[n]`	as above	as above	as above
Note: [n] represents the number of decimal digits

Figure 3-9 “Example of a Field Extending over Several Lines” shows valid application data types and their values in COBOL, Pascal and FORTRAN.

Table 3-9 Valid Application Data Types

FORMSPEC	COBOL	Pascal	FORTRAN
`CHAR`	`X`	`Packed array CHAR [.._]`	`CHAR *_`
`YYMMDD`	`X(6)`	as above	`CHAR *6xx`
`ZONEn`	`9(_)Vn`
`PACKn`	`9(_)Vn COMP-3`
`SPACKn`	`S9(-)Vn COMP-3`
`REAL`		`REAL`	`REAL`
`LONG`		`LONG`	`Double Precision`
`INT`	`S9(4) COMP`	`Subrange -32768..32767`	`Integer **2`
`DINT`	`S9(4) COMP`	`Integer`	`Integer **4`

Initial Value

You may specify an initial value for the field. This value will be displayed in the field when the form is first displayed at the terminal. It is also displayed when REFRESH is pressed during data collection in ENTRY and the form is cleared to its initial values.

The value entered here is treated like user input. That is, it must match the data type of the field and must not be longer than the field length.

(Refer to Section 4 for a discussion of how FORMSPEC uses these data types to perform validity checks on data entered in the fields, and how data is treated during movement from one field to another.)

If Native Language Support is used, you must specify the initial value in NATIVE-3000. The value will appear with the conventions of the native language at run-time. For more information on Native Language Support, see Section 8.

Understanding Form Sequencing

As shown in Figure 3-4 “Sequence of Menus for Form Design”, the Form Menu is the first menu in the sequence of menus used to define a form. On the Form Menu, as shown in Figure 3-10 “Example of a Form Menu”, you specify a name for the form and the form sequencing options to use ( Repeat Option and Next Form The form sequening options are described below. the other fields pertain to advanced features such as "Form Families" discussed later in this section.

Figure 3-10 Example of a Form Menu

The Repeat Option

When the forms in a forms file are displayed, a form may be repeated and appended to itself (A); it may be repeated overlaying the previous display of itself (R); or it can be a non-repeating form that is displayed once (N).

To illustrate how the three choices of the repeat option work, assume that form X is a repeat/append form (A). This form is displayed, the user types in data, and presses ENTER. The form with the data remains on the screen, and the same form with no data (except initial values) is displayed Immediately below the form with data. The next time ENTER is pressed, the form is displayed a third time immediately below the second form. This continues until the repeat option is changed.

Appended forms are particularly useful when the form is a single line that has an indeterminate number of iterations. An order entry blank, for instance, could be designed as a repeat/append form.

A form that repeats without the append option (R) is cleared each time the user presses ENTER to enter data. For example, assume form X is a repeating form that overlays itself:

Note that this type of repeating form overlays itself even if there are other forms on the screen.

The Next Form Option

You specify the name of the next form to be displayed after the current form or keep the default of $HEAD. You may also specify whether the next form is to be appended to the current form (A); and, if appended, whether the current form is to remain frozen on the screen when the screen fills up (F). If the screen is to be cleared before the next form is displayed, keep the default of C.

The following examples illustrate how freeze (F) and append (A) interact with the current form. Assume a current form X and a next form Y. The next form (Y) is defined on its own Form Menu as a repeating form appended to itself (repeat option = A for Append).

Current Form X -- Repeat Option = N Next Form Option = C
Next Form Y -- Repeat Option = A
Form X is displayed, then after ENTER, the screen is cleared and form Y is displayed. After the next ENTER, Y is repeated below itself until the user presses NEXT or the application changes the repeat option.
Current Form X -- Repeat Option = R
Next Form Option = C
Next Form Y -- Repeat Option = A
X is displayed until the repeat option is terminated, then Y is displayed and appended to itself until the repeat is terminated again.
Current Form X -- Repeat Option = A
Next Form Option = C
Next Form Y -- Repeat Option = A
X is displayed and then appended to itself until the repeat option is terminated. Then the screen is cleared and Y is displayed.
Current Form X -- Repeat Option = N
Next Form Option = A Next Form Y -- Repeat Option = A
X remains on the screen while Y forms (in this example, two copies of Y) are appended to it until no room is left on the screen. When the third copy of Y is appended, form X (or part of it) is rolled off the screen and deleted to make room. However, if the next form Y(1) filled the screen below X, Y(1) would be rolled off and deleted before Y(2) is displayed.
Current Form X -- Repeat Option = A
Next Form Option = A
Next Form Y -- Repeat Option = A
Form X is repeated and appended until the repeat is terminated. When the first Y form is displayed, there is no more room for the first X and it is rolled off the top of the screen and deleted. As new Y forms are appended, the X forms continue to be rolled off and deleted.
Current Form X -- Repeat Option = N
Next Form Option = FNext Form Y -- Repeat Option = A
Form X remains frozen on the screen as form Y is appended to it. When the screen is filled, X remains frozen on the screen while the oldest Y form, Y(1) is rolled off to make room for Y(3). Note that if Y(l) fills the screen below X, it will be rolled off the screen and deleted when Y(2) is displayed.
Note that the F specification determines what happens when the screen is full, The A specification determines what happens when the next form is displayed. If an appended form does not fit on the screen with a frozen form, the freeze specification is cleared and the frozen form is rolled off the screen and deleted until the entire next appended form fits.
Current Form X -- Repeat Option = A
Next Form Option = F
Next Form Y -- Repeat Option = A

Form X is appended to itself. When the repeat is terminated, the first Y form is appended to the last X. When the next Y form is displayed, the first Y is rolled off the screen and deleted leaving the remaining X forms on the screen.

Note that if one frozen X forms should fill the screen, the first X is rolled off and deleted to make room for the latest X, and when the first Y form is appended, the X forms are no longer frozen.

Sample of Forms Design

Before running FORMSPEC to define your forms file, it is very helpful to decide on some of the basics of forms design, such as:

Consider what kind of data the user will be entering — character, numeric, or date.
Determine the position of the fields — what order, how many on a line, which need to be on the same line, the same form.
Decide on which enhancements to use for each field.
Take into account what type of terminal the users will have. Are there any special features? Will they be used?
What native language will be used?
Will the forms file be used with ENTRY or with an application? How will form sequencing be handled? Do function keys need to be defined? If so, which ones?

Not all of these questions need be answered prior to forms design, since FORMSPEC provides defaults for most form and field characteristics. Still, you may find it helpful to roughly sketch each form layout on paper, something along the lines of the example in Figure 3-11 “Sample Forms File Layout” The field name and length should be noted, and if a field has special (nondefault) characteristics, these too may be noted on your preliminary sketch, as was done in Figure 3-11 “Sample Forms File Layout” Preparing your forms layout in this way allows you to then sit down at the terminal and actually specify the complete forms file in a matter of minutes. You may find that completing the form layout and accompanying Field Menus is sufficient to define the characteristics of all fields on the form. In many cases, the default values supplied by FORMSPEC can be used, thereby reducing your actual input to a minimum. However, as you become familiar with the capabilities of VPLUS, including the processing specifications of FORMSPEC, described in Section 4, and the intrinsics available to applications, described in Section 6, you may find yourself taking advantage of the additional options as you finalize the design of your forms file.

The example in Figure 3-11 “Sample Forms File Layout” answers many of the questions listed above, both graphically and in accompanying notes. This forms design, when entered through the FORMSPEC menus, will generate a set of forms similar to those used as a data entry example with ENTRY in Section 2. (What data will your application need? How should it be laid out?) For forms sequencing, note that the first form is "frozen" on the screen, the second form is appended to the first and is repeated until the user presses NEXT to display the next and last form, TOTALS. (In this example, since ENTRY is used, the ENTRY function keys are used as well as the forms sequencing options of the Form Menu. Is this true for your design?) When TOTALS is displayed, all previous forms are cleared from the screen. Up until that point the first form is frozen on the screen. Should the second form be repeated so many times that there is no more room on the screen, its first appearance is rolled off while the first form remains on the screen. (How will you handle multiple forms?) These are some of the questions you should consider when designing your own forms file.

Figure 3-11 Sample Forms File Layout