Using Verifile to Call a Second Window

Published ByDateVersionKnowledge LevelKeywords
Revelation Technologies17 JAN 19912.XINTERMEDIATEVERIFILE, PATTERN, VALIDATION

Through the Verifile validation pattern, Advanced Revelation provides a mechanism that ensures that your entry is a key in another file.

For example, in an invoices entry window you want to be sure that the customer number entered exists in the customers file.

Verifile can take up to 5 parameters. If present, parameters 4 and 5 are a code and command that are executed if the verifile fails. This code and command can be used to display a message, present a popup of valid entries, or to call another window.

Consider the following example:

An application consists of a Customers file (and window) and a Zipcodes file (and window). The Zipcodes file maintains a list of valid US zipcodes and the cities and states associated with each zipcode.

In the customer window you enter the zipcode and the associated city and state are displayed automatically, via symbolic fields.

If, however, the zipcode you entered does not yet exist in the Zipcodes file (that is, it should be there but is not), you want to be able to enter the zipcode.

The program in Figure 1 is called from two places: the Validation Pattern of the Zipcode prompt in the Customer window, and as a post save process in the Zipcode window.

The Validation prompt looks like:

<ZIPCODES,,,S,CUSTOMER_ENTRY_SUB>

Note that Verifile does not yet support the passing of a branch to the subroutine.

The post save process takes a code of S and a command like this:

CUSTOMER_ENTRY_SUB,XXX

The XXX serves as a placeholder. The program doesn't care what is in branch, just whether or not something is there.

The program uses @USER4 to pass information between the windows. It tries to allow for the possibility that other processes might be using the variable by saving off and restoring the original contents.

However, if some other process on your system is setting @USER4 and not cleaning up, you will find that the Zipcode window quits after every record entered, even when the window is not called from the Verifile routine.

Figure 1

SUBROUTINE CUSTOMER_ENTRY_SUB (BRANCH)

$INSERT INCLUDE, WINDOW_COMMON%

EQU TRUE$  TO 1
EQU FALSE$ TO 0
EQU NULL$  TO ""

DECLARE FUNCTION UNASSIGNED
DECLARE SUBROUTINE CATALYST

IF UNASSIGNED(BRANCH) THEN
  /* The routine is being called as part of VERIFILE */
  /*
  @USER4 stores the user's input, and is used to indicate that the
  ZIPCODES window should quit after the first record is entered.
  */
  SAVEUSER4 = @USER4
  @USER4    = @ANS ;* any of the @USER variables can be used
  /*
  Call the ZIPCODES window, using the user's entry as the key
  */
  CATALYST("W", "ZIPCODES " : @USER4)
  /*
  The transfer command will move the current contents of @USER4 to @ANS.
  This has the effect of nulling out @USER4 and, thus, resetting the flag.
  */
  TRANSFER @USER4 TO @ANS
  TRANSFER SAVEUSER4 TO @USER4
END ELSE
  /*
  There is a branch argument provided. Therefore the routine is being called
  as a post save process in the ZIPCODES window.
  */
  IF @USER4 THEN
    /* The window was called as part of VERIFILE*/
    @USER4 = @ID ;* Put the key in @USER4, it may be different from
    * what was entered in the CUSTOMERS window.
    WC_WDONE% = TRUE$ ;* Tell the window processor this window is done.
  END
END
RETURN
  • tips/revmedia/r70.txt
  • Last modified: 2024/06/19 20:20
  • by 127.0.0.1