# Triggers Used Only on INPUT Processing Tables

@keyX

When user presses key "x" (or "X", case is not significant) while sitting at the "Enter Selection >" prompt.

@key can be used with any plain text character key on the keyboard. Special keys (TAB, ENTER, SAVE, etc.) are not usable with @key.

This processing can be activated by the user while sitting on a record with the cursor at "Enter Selection" prompt (or custom prompt).

Pressing the designated key locks the record (multi-user), runs the AUTOMATIC table first, and then runs the @key processing, starting at its label following the table directions until an END is encountered. At this point, the AUTOMATIC table is run again and the process is finished.

IMPORTANT: The AUTOMATIC table's first job is to clear all regular dummy variables. If you set a variable inside your @key processing and expect it to retain that value, you must make this variable "global". The AUTOMATIC table does not clear global variables.

NOTE: Be sure that there is always a "then" line above your @key process which will not allow the INPUT table processing or other @when processing to "fall through" to this @key code. This will, of course, give you undesirable results. If there is no INPUT processing and you want to build an @key routine, put an END statement on line 1's "then" line, and build the @key starting from line 2. This way, when the user SAVE's the record, the @key process will not be run as if it were the INPUT table processing.

IMPORTANT: On multi-user and network systems, @key processing "locks" the current record. If other users are running reports or processing that select this record, they will be stopped in their tracks until the lock is removed. For this reason, you should not put up processing MENU's with @key. Also, be careful not to put up message boxes or the like which require that the user press a key to bring them down. More likely than not, someone will inadvertently leave such a message on the screen and go to lunch. This hangs everyone else up who needs access to that record. A better idea would be to use the SLEEP command and display the message for a reasonable amount of time and then bring it down within your own @key code.

Example:

@keyT if:

then: show "@The time is"<@tm ; end

The T is capitalized only for clarity when reading the code. (Processing_tables tables are insensitive to cAsE.)

The above will certainly work, but it forces the user to press ENTER to finish the @key process. Instead, try:

@keyT if: 'on Unix, use sleep "3"

then: show "The time is"<@tm ; sleep "3000" ; end

This will show the time for 3 seconds and then automatically end the processing, leaving nothing up to the user.

Of course, if the @key process is supposed to put the user into UPDATE mode so he can add to or modify the record or perform some other task, this is perfectly acceptable and a great use for @key processing. You have to assume that the user will finish such a task before leaving for lunch.

@key processing can be tricked into working from other parts of the INPUT processing table. This is done with

PUSHKEY. As in:

if:

then: pushkey "T" ; end

When this code is encountered, filePro waits for control to be returned to the user, and just before it accepts input from the keyboard, it generates the designated key (in this case T). Since the @keyT is triggered by this event, it happens just as if the user had activated it himself. If there is no @keyT processing on the INPUT table, nothing will happen.

Processing_tables to do after record is displayed, but just before the prompts are displayed and the cursor is placed at the "Enter Selection" prompt.

This processing does NOT lock the current record. This means you can not write to real fields within an @entsel routine.

A common use for @entsel is to combine it with the -d flag of clerk. This flag tells filePro to clear the standard prompts off the bottom of the record screens. This allows you to put up custom prompts of your own. Using @entsel will put these custom prompts up at the appropriate times.

For example: The following command line and code will display a custom set of prompts. It would be up to you to make sure there are appropriate @keys for each of the displayed prompts. Just changing the prompts will not stop filePro from intercepting the keys it normally does like (H)ardcopy, (B)rowse, (U)pdate and so forth. They will still be active unless you build @keyH, @keyB @keyU processing of your own. Any combination of filePro (factory installed @keys) and custom @keys of your own is acceptable, just remember that yours will override the factory supplied @keys.

rclerk filename -s1 -d

@entsel if:

then: show "\r P \r-Print, \r U \r-Update, \r M \r-Modify, \r X \r-Exit"

if:

then: end

IMPORTANT: Remember that @entsel processing does NOT lock the record on multi-user systems, so you can not make assignments to real fields within the @entsel code. In other words, a real field can not be the left side of an equals statement.

@menu

Processing_tables done just before the clerk menu appears.

@menu processing can only be used on INPUT tables. It is activated just before the clerk menu appears on the screen and, this is IMPORTANT, it is activated EVERY TIME the clerk menu is just about to appear on the screen. This can be very confusing at first. More than likely, you will want the @menu code to work just once, the FIRST time the user ENTERS this file. You probably do not want to run it again when the user is LEAVING the file. This can be accomplished by setting global dummy variables to control the processing.

Let's assume that you want the @menu processing to bring the user to "his" record in a file. You do this by asking for his initials and then moving him directly to that record with "lookup -". This can be done as follows:

@menu if:

then: input popup in(3,allup) "What are your initials? "

err if: in eq "" 'no answer,

then: errorbox "Sorry, those initials not on file." ; exit

if:

then: lookup - k=in i=A -nx

if: not -

then: in="" ; goto err

This code will allow the user to put in a good set of initials (on file) and take him directly to that record. Blank initials or not on file initials will kick him out of the program. However, there is one glitch. When the user is done with the task on his record and wants to exit the program, the @menu program keeps asking for his initials, it doesn't know he wants out! Of course, users could press ENTER and the program would throw them out for blank initials, but there is a better way, and it is the key to making @menu work in most other situations as well. Set a "flag" to tell @menu what to do on the way in and on the way out. Do this with a global dummy variable. It means adding 2 lines above what is already shown, and something like this should probably be in most @menu routines.

@menu if: f eq "1"

then: exit

if:

then: f(1,,g)="1"

if:

then: input popup in(3,allup) "What are your initials? "

err if: in eq "" 'no answer,

then: errorbox "Sorry, those initials not on file." ; exit

if:

then: lookup - k=in i=A -nx

if: not -

then: in="" ; goto err

This flag will be empty the first time into clerk, so the user can get to his record. But, this time when he tries to exit the program, the value of f will be "1" and it will happen.

If you want the user to be able to stay in the program and make use of the clerk menu, this EXIT could be an END statement. This would leave the user at the clerk menu. Remember, @menu processing executes all the @menu code it encounters and then puts up the clerk menu. If all it encounters is END, it does nothing and puts up the menu.

There are a variety of things you can do with @menu in terms of taking users in and out of files and records. A powerful combination is to use @menu with PUSHKEY. Examine the following:

@menu if: f eq "1"

then: exit if:

then: f(1,,g)="1"

askin if:

then: input popup in(1) "1) Indexes\n2) BALDUE selection set\n====> "

if: @sk eq "BRKY" or @sk eq "ENTR"

then: exit

if: in ne "1" and in ne "2"

then: goto askin

if: in eq "1"

then: pushkey "4" ; end

if: in eq "2"

then: pushkey "22LBALDUE[ENTR][ENTR]" ; end

This asks the user whether he wants to go into the file using indexes, or to go directly to the first record that matches the criteria on the BALDUE selection set. This is NOT very robust or useful code, but it shows how PUSHKEY and @menu can work together.

NOTE: @menu processing is performed while the user is standing on record 0. There are no real fields available.

@update

Starts input processing before user is put into update mode. This processing allows you to do things AFTER the user has pressed "U" to UPDATE the record (or whatever key is assigned to perform this function) and BEFORE the cursor hits the first field on the cursor path. (Or before it hits any @wef processing which may be attached to that first field).

@wefNNN When entering field "nnn".

@wlfNNN When leaving field "nnn".

@wblNNN

Responds to browse lookup key (keylabel DMAP) when in field "nnn". If there is an existing browse lookup for this field, it is not performed.

@whpNNN

When the user presses help key (keylabel HELP) when in field "nnn".

@wukNNN

When the user presses any of keylabels (DPRT, GRAF, INSL, DELL) when in field "nnn". Once the user presses one of these user keys, you can use @sk to determine which of the 4 were pressed. The default user key is DPRT.

@w??*

The '*' character can be used in place of the "nnn" field number in WEF, WLF, WBL, WHP, WUK.