How A Processing Table Works

It is important to understand the "operation" and flow of the various processing tables.

Simply put, the operation of a processing table is a matter of "stop and flow". When you update (or create) a record, the cursor is put on the first field available on the screen (or the first one specified by the cursor path) and control is handed to the user. When the operator is finished entering data on this screen an interactive program called the input processing table is run. The most basic way this program is started is by the action of the operator pressing the SAVE command (Unix=ESCAPE ESCAPE, DOS=ESCAPE). At this point the "program pointer" starts from line number 1 of the input table and progresses as directed from line to line, executing each "then" line for which the "if" line is true. If the "if" line is false the program "falls through" the "then" line WITHOUT executing it, to the next "if" line and tests it, etc. etc. A "then" line can direct the program to "GOTO" a different "if" line instead of the one immediately following. The program continues executing each line as directed until certain commands which stop the flow are encountered. Commands that stop the flow are "then" lines which hand control back to the operator. The two most basic commands that do this are the SCREEN command and the INPUT command.

The SCREEN command switches the user to another screen so he can see and enter data in other fields. When a SCREEN command is encountered, the user is placed on that screen and control is once again handed back to him. The IMPORTANT thing to learn is that the program counter is sitting at whatever line the SCREEN command was on in the processing table. The next time the user presses SAVE (ESCAPE/ESCAPE), the program (the input table) will start running with the command immediately after the SCREEN command. It DOES NOT start from line number 1 as it did before.

There are several commands that can hand control back to the user. It is this interaction of user and program that eventually brings you to an END statement or the literal end of the input table. If you are in Add Records mode, you will be brought to the next available record and the cursor is deposited on original screen you saw when you first entered Update mode. The input table program pointer is sitting at line 1 again waiting for the user to press ESCAPE/ESCAPE on this new record. If you are not in Add Records mode, the cursor is brought to the Enter Selection prompt.

To demonstrate this "stop and flown, consider the following input table. It demonstrates some aspects of program flow control. (We will assume there is no automatic processing on this file.)

An English translation of this table is as follows. When the operator presses ESCAPE ESCAPE the first time, the program pointer starts at line 1. Because there is no "if" condition the process fills field 15 with the value of 12 plus 13 plus 14 (presumably just entered by the operator on the screen he was on).

Because there is no "if" condition on line 2, the process switches screens to screen 2 and hands control back to the operator by putting his cursor in field 9 on that screen. The program pointer stops here and must wait for the operator to enter or view data on screen 2. The program is stopped and waiting. When the operator is finished on this screen and presses ESCAPE ESCAPE, the program picks up at the point where it left off, and executes line 3 (because once again there is no "if" condition). Field 3 is filled with the value of field 15 times the value of field 2.

The process then moves to line 4. Here it tests the "if" condition. If the value of field 3 is greater than "100", the user is sent to screen "credit" and the program pointer stops right there. If it proves false (3 is equal to or less than "100"), the program falls through the "then" to line 5. Because there is no "if" condition on line 5 sets field 4 equal to a "Y", and then ends. If the test of line 4's "if" condition did prove true, the program will be waiting for the operator to press ESCAPE ESCAPE to record the "credit" screen. At this point the process picks up with the command immediately following the SCREEN command which means it goes to the line labeled "quest".

Here the INPUT command both alerts the operator to something and waits for a response. The program pointer is waiting once again at line 6. This time, however, the operator must supply an answer to the INPUT statement. He cannot just press ESCAPE ESCAPE it will have no effect. His answer is placed in the dummy field (also called a variable) "q". The dummy field "q" has an edit type of "yesno", which means only a "Y", an "N", or a RETURN is accepted by filePro as legitimate answers. Anything else will generate an Edit Failed error. The process tests "q" for each of these possibilities and does something different for each answer.

As soon as the operator answers the question, the program pointer moves to line 7 and tests to see if RETURN was pressed. (If this is true "q" will be filled with nothing, represented as "". This is referred to by programmers as "null".) If "q" is null, then the process sends the operator right back to the line labeled "quest", because we need either a Y or N answer. We are in control, not him! The program displays the INPUT question again and waits for a better answer this time. If he keeps answering with RETURN, he keeps getting the INPUT question. When he finally gives in and answers with either a "Y" or an "N", the "if" condition on line 7 tests false, because "q" is now not null and the process falls to line 8. If the operator answered "Y", field 4 is filled with a "Y" and the program ends. If the operator answered "N", field 4 is filled with an "N" and the process ends.

NOTICE that there is no "if" condition necessary for "q" being equal to "N". This is so, because if "q" is not equal to "" and it is not equal to "Y" the only other value the "yesno" edit would have allowed the operator to enter was "N". Therefore, if the process hits that line, we know "q" must be equal to "N". We have provided for the other two possibilities before this line is reached. (It would do no harm to have line 9's "if" condition read q eq "N", but you might as well get used to the usual programmer obsession of not writing any code that isn't absolutely necessary.)

By directing users through your screens with logic that forces them to do only what you allow; and by using edits which force them to give only answers that you have completely covered in your processing, you can start to write simple filePro tables that will do what you want done and not what the computer wants done.