There are several kinds of processing "triggers". This section will cover @when leaving and @when entering triggers. They are used only on the INPUT processing table.
When you first work with FilePro processing tables, you are happy to find that math can be performed on the data: payments subtract from charges to leave balances due, columns of figures add up into totals, and due dates pop into place. You can be shown help, moved to other screens, or be presented with menus, all matter of magic can happen to your screen after you press the ESCAPE ESCAPE sequence. In many instances, though, it would be wonderful to do some of this magic before storing the record. This can be accomplished by using the @when processing feature of FilePro. Pronounced "at when" processing, this is only one type of trigger that filePro can intercept.
There are several kinds of @when processing; we will discuss two here, @wlf (at when leaving field) and @wef (at when entering field). These are triggers that can initiate a processing routine. For instance, when you leave field 22, the date field of an invoice, you want to immediately calculate the due date (say 30 days from this date) and display it in field 23. Your input processing table (@when processing NEVER goes on the automatic table) might look like this:
If:
Then: end
@wlf22 If: 22 eq ""
Then: 23 = "" ; display ; end
If:
Then: 23 = 22 + "30" ; display ; end
In English this processing says: when the cursor leaves field 22, if field 22 is empty (programmers say, if 22 is equal to null or if 22 is null) then set field 23 equal to null. Then display all the fields on the screen with their most current values, then end. (In other words, this little snippet of processing is done, so end it and put the cursor into the next field on the cursor path.)
Note 1: There is an end statement above this processing. You must not allow other processing to fall into an @when leaving or @when entering routines. The line above them must either stop the processing or direct it somewhere else, such as "goto label", "return", "exit". For now, and until you get far more advanced, it is a safe idea to put all of your @when processing snippets at the end of your regular input processing (the stuff that happens when you press ESCAPE ESCAPE) and be sure there is an END statement immediately preceding each @when label. (or something that will not let the processing fall through by mistake.) (Advanced users can use @when processing as a label, but this is because they thoroughly understand the difference between using it as a trigger and as just another piece of regular code.)
Note 2: All branches of each @when processing must be "stopped" correctly. There are five commands that will correctly stop an @when process (END, SCREEN, SKIP, ESCAPE, EXIT), and they do JUST THAT. Study the following example. Let's say you want the operator to be brought to SCREEN 2 when his cursor leaves field 17. On SCREEN 2 are some fields (13, 14 and 15) which you want to add up and put into field 16 when the operator is done on SCREEN 2. You have written the following code:
If:
Then: end
@wlf17 If:
Then: screen 2
If:
Then: 16 = 13 + 14 + 15 ; display ; end
Everything looks beautiful, right? NO! The SCREEN command is an "ending" command for the @when processing. True, leaving field 17 will cause that command to happen, but that is it! The processing on line 3 will never get executed. When the operator presses ESCAPE ESCAPE on screen 3, the processing table will pick up wherever the program counter was last sitting (probably at the top of the INPUT table). Why? Because that is where input processing starts and INPUT processing is the table that is run when ESCAPE ESCAPE is pressed. Just because the @wlf and @wef trigger processes are on this table, does not mean they get executed when ESCAPE ESCAPE is pressed. They ONLY get executed when their trigger is pulled when the user actually moves the cursor into or out of the field they specify. Line 3 of the above code will never be reached.
These are the two keys to understanding @when processing. First, every possible branch of actions must eventually be ended with an "ending" command (one of the 5 listed above). The real INPUT table program counter/pointer has never moved, and will never move because of a trigger process being executed. It stays right where it is. The next line that will be executed when next INPUT processing is called (ESCAPE/ESCPE) is the same one that would have been executed with or without any @when processing..
The same rules apply to @when entering processing. An example might be the following. You have a new employee, Fred, who is allowed to change anything on a record but the price field 14. All of your other operators CAN change this field. Your code might look like this:
If:
Then: end
@wef14 If: @id eq "fred"
Then: skip
If:
Then: end
It may look strange, but it is correct. As the cursor "enters" field 14, this processing routine is triggered. FilePro checks the user ID of the operator and if it is equal to "fred", the process skips this field and deposits the cursor (and Fred) into the next field on the cursor path. Any other user ID and the process just ENDS. Which, in this case, leaves the cursor right where it was headed, field 14. In other words, there was NO @wef14 processing, jut do nothing.
Using @when Leaving As Powerful Edits.
One thing you often want to do is disallow certain data in a field. You might use something like the following to accomplish this :
If:
Then: end
@wlf3 If: 3 eq "whatever-you-don't-want"
Then: beep; show "@Sorry, wrong data"; 3=""; screen 3
If:
Then: end