GOLD 
HOME Moves the cursor to the first field when in the ADD or UPDATE mode.
Data is entered onto the Form Description screen in much the same way as data is entered onto any data entry form. In formdef, however, the function keys are used slightly differently. Their functions are outlined in the table below.
F1 GOLD
F2 PREVIOUS
F3 NEXT
F4 UPDATE
F5 STORE
F6 ADD
F7 SWITCH
F8 EXIT
The GOLD <F1> key is used in the same way as it is in form. The GOLD <F1> key, followed by another key performs additional functions.
The PREVIOUS <F2> key displays the form description that is before the form description currently on the screen. If there are no forms before the current form, formdef displays a No more forms error message. If you press the PREVIOUS <F2> key again, formdef displays the last form in the formfile. The order that form descriptions are displayed depends strictly on the order they are stored in the formfile.
The NEXT <F3> key displays the form description that is after the form description currently on the screen. If there are no forms after the current form, formdef displays a No more forms error message. If you press the NEXT <F3> key again, formdef displays the first form in the formfile. The order that form descriptions are displayed depends strictly on the order they are stored in the formfile.
To modify the current form description, press the UPDATE <F4> key. After you make all the modifications, press the STORE <F5> key. If you press the UPDATE <F4> key while in UPDATE mode, formdef redisplays the original contents of the Form Description screen.
To add a new Form Description, press the ADD <F6> key. Formdef clears the Form Description fields and allows you to enter data. When you press the STORE <F5> key, formdef displays a blank screen, and you can begin to enter the form itself.
To switch to the actual form that corresponds to the current form description, press the SWITCH <F7> key. Pressing SWITCH <F7> again redisplays the Form Description screen for that particular form.
Pressing the EXIT <F8> key causes formdef to write out all the forms to the formfile and exit.
The extra functions that are implemented with the GOLD <F1> key are very similar to their counterpart in form. They are:
GOLD D DELETE Deletes the current form from the formfile.
GOLD H HELP Displays on-line help.
GOLD R REFRESH Erases the screen and redraws the current form. This is useful if the data entry screen
become garbled.
GOLD X CANCEL Cancels the current operation (ADD or UPDATE) and returns to no mode.
GOLD 4 CLEAR Clears all entry fields when in the ADD or UPDATE mode.
GOLD
The first step in creating a form is to describe some attributes of the form. This is done by entering data on the Form Description screen as shown below.
Each form stored in a formfile has a name, and the name is entered into the Form Name field. Each form should have a unique name within the formfile.
Each form is associated with an RMSfile and is used to enter, query, update, and delete records in that RMSfile. The name of the RMSfile is entered in the Data File field on the Form Description screen. The RMSfile name can be a logical name or the path name of a RMSfile. If the RMSfile name is a logical name and it does not specify a database, the DBASE environment variable must be set to the name of the database. See Chapter 2, Databases for more information about logical names. Formdef checks that this is a valid RMSfile name and opens the corresponding RMS dictionary file for later processing.
When form starts, it displays one of the forms from the formfile. You specify the form to be displayed first by setting the Beginning Form field in the Form Description screen to yes for that form. For all the other forms in the formfile, you should set the Beginning Form field to no.
Each record stored in a RMSfile is identified by one or more fields within that RMSfile. These fields are called key fields For example, the invoice number field can be used to identify each invoice stored in the invoice RMSfile. When you set the Unique Records field in the Form Description screen to yes, then form does not allow records with duplicate keys to be stored into the RMSfile. If you set the Unique Records field to yes for the invoice RMSfile, each invoice entered must have a unique invoice number. If the Unique Records field is set to no, any number of records with the same key fields may be entered into the RMSfile.
The next three form attributes, Repeating Form, Append Form, and Freeze Form, describe what action is to be taken after one record has been processed by form. Normally, form continues from one form description to the next after completing (storing) one data record. Form clears the screen and displays the next form (specified by the Next Form Name field) on the screen. These three attributes let the forms designer modify that sequence.
If you set the Repeating Form field to yes, form repeats the current form indefinitely, rather than continuing on to the next form. The screen is not erased in between records; form only erases the fields and reuses the current form. When the operator does wish to continue on to the next form, the operator must push the NEXTFORM <F7> key.
If you set the Append Form field to yes, form displays the form below the previous form, instead of displaying the form at the top of the screen. This allows you to stack forms, one under another, on the screen. If there is not enough room left on the screen for the new form to fit, the lines on the screen are scrolled up until there is sufficient room. If you set both Repeating Form and Append Form to yes, each new form is the same, and the new form is appended to the bottom of the previous form. Each appending form is added after the last line of the previous form. An example of this feature is given in a later section.
If you set the Freeze Form field to yes, this form and any displayed above it are not scrolled upwards when subsequent appending forms cause scrolling. Instead, this form is frozen on the screen.
For example, two different forms might be used to enter invoices. The first form would be the header information for the invoice and would contain the invoice number, customer identification, shipping instructions, and so forth. The second form would be one line item for that invoice. If this second form had the Repeating Form and the Append Form fields set, any number of line items could be entered for the invoice. If a sufficient number of line items were entered, the header information would be scrolled off the screen. If, however, the Freeze Form field were set to yes for the invoice header form, it would always stay on the screen, and only the oldest invoice line items would be scrolled off the screen.
Usually, a data entry form fits easily on a screen. It is possible, however, to create a data record so large that you could not fit all of its data fields on the screen. In this case, the form may be split into several different forms, each accessing only some of the data fields in the data record. The RMSfile name specified on each of the Form Description screens must be the same for each of these different forms.
The first form that accesses the data record would have the Additional Form for One Record field set to no, and a data record would be created when the operator pushes the STORE <F5> key in ADD mode. In the second and subsequent forms, the Additional Form for One Record field would be set to yes. This tells form that the data fields entered into this form are to be added into the record created by the first form using this RMSfile, rather than creating a second data record.
When the Additional Form for One Record field is set to yes, form does not create a new record in the RMSfile. Instead, form rereads the previously created record, and the contents of all of the fields from the current form are inserted into that record. This updated record is then written back into the RMSfile.
When more than one form is used for a data entry session, you may require that data be entered into one of the forms. If you set the Required Form field to yes, then that form must be used to add or update a record.
For example, this might be used on a formfile that has a header form, a second form used for entering detail lines, and a third form with sales tax information. If the third form has the Required Form field set to yes, then the user must update or add a record in the sales tax form.
The operator may not skip any forms if one of the following forms has the Required Form field set to yes. The user must proceed through all the forms to the required form, and then change the required form. If any of the invoice lines are changed in our example, the sales tax form must also be updated.
This rule is enforced only if changes were made to previous forms. If the user was just finding and displaying records, having the Required Form field set to yes for a following form does not force the user to proceed to that form.
The last field on the Form Description screen specifies the Next Form Name. This field must contain the name of a form stored in the formfile. If the Repeating Form field is set to no, after one record is processed, form switches to the form named in the Next Form Name field. If the Repeating Form field is set to yes, form goes to the form named in this field only after the NEXTFORM <F7> key is pressed. If there is only one form in the formfile, then the Next Form Name field must contain the same name that is in the Form Name field.