Description:
Processing 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
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
Then: f(1,,g)="1"
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
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
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 may NOT very robust or useful code, but it shows how PUSHKEY and @menu can work together.
Notes :
@menu trigger is used only on INPUT processing table.
@menu processing is performed while the user is standing on record 0. There are no real fields available.
When using a lookup-dash in @MENU routine, it will override -X flags.