In the examples up to now, the subscription RMSfile has had its own form for entering information. Normally, a subscription is thought of as belonging to a particular subscriber. A form can be created that would represent that relationship. The formfile that we will create consists of two different forms. The first form is much like the subscriber form that was used previously. The second form is a repeating form that is appended to the subscriber form, and it shows all the subscriptions that belong to the subscriber entered using the first form. The final result that is created looks like the screen below. Several of the repeating subscription lines are shown, to give a idea of how the form looks.
In this example, invisible fields, the copy attribute and multiple forms are all demonstrated. The formfile consists of two separate forms.
The first form that is created is the subscriber header form. A title line has been added at the bottom of the form to label the subscription lines that are appended.
The Form Description screen for the above form is:
This first form is not a repeating form. This causes form to continue immediately into the next form after a record is processed on the first form. Also, the Freeze Form field is set to yes. This causes this form to stay on the screen no matter how many subscription lines are displayed underneath the first form. Instead, the oldest subscription lines are scrolled off the screen to make room for new ones.
The second form in the formfile represents the repeating subscription lines displayed underneath the subscriber form. The Form Description screen for this second form would be:
The second form uses the appending and repeating form attributes. This causes the second form to be added to the bottom of the first form rather than to be displayed on an erased screen. Also, the second form repeats, so that all the different subscriptions for one subscriber can be displayed, one after another.
The form itself consists of a single line, representing one subscription record.
It would still perform a validation of its contents against the magazine RMSfile. After a magazine code is entered or displayed, the magazine title would be shown in this field. The next two fields are the started field and the issues field. They are normal data entry fields.
The solitary field on the second line is an invisible field. It is shown here with asterisks, but formdef shows this as a blinking field. This field represents the subscriber field in the subscription RMSfile. Its Field Description form would look like:
The subscriber field in the second form is not displayed on the screen, but instead, its value is copied from the subscriber field in the first form. This field is the key field for the script RMSfile. This field is used when doing FINDs, since it is part of every QUERY. In this way, only subscriptions belonging to the subscriber shown in the first form is entered or displayed on the second form.
This last example demonstrates the method that would be used for creating entry forms such as invoices that have multiple line items. The invoice header is stored in one RMSfile, and all of the detail line items are stored in a second separate RMSfile. Splitting up an invoice in this manner allows the user to enter as many invoice line items as desired, rather than providing a fixed number of line items in the invoice record. The user need not be aware that the invoice is actually being stored in two separate RMSfiles. To the user, the invoice would seem like one variable length record.