View Source

Consider the following input screen generated by an RDML REQUEST command. It requests that the user input a company number, a department number and an invoice number.

Note also that the prompt key is enabled (and is handled automatically):

^{INVOICE01 Invoice Inquiry}

^{Company number . . . ____}^{Dept number . . . . . . . . ____}^{Invoice number . . . . . _________}

^F4=Prompt

If the user tabs into the field department number, and uses F4, the following processing occurs:

The cursor location is examined and determined to be within the boundaries of field department number. If the cursor is not within the boundaries of a field, the screen is re-displayed with an error message indicating that the cursor must be within a field's boundaries when the prompt key is used.
The definition of field department number is located in the Repository and the associated prompting process/function extracted. If no prompting process/function exists for the field the screen is re-displayed with an error message indicating that the prompt key is not available for the field.
The following information is posted to the exchange list:
Field values defined in EXCHANGE OPTION(*ALWAYS) commands
The current value of department number (i.e., the prompted field)
If the field department number refers to another field for its definition, then its value is posted again, but under the "referred to" field's name.
Special fields PROMPT$FN and PROMPT$RN are placed onto the exchange list. These fields contain the name of the field that is being prompted and the name of its associated reference field (if any) respectively. These fields should be defined in your repository, allowing you direct reference to them. If not, define them both as alpha (A) fields of length 10. They are supplied to the prompting process/function to allow it to determine which field is being prompted.
If position 499 in the system definition data area DC@A01 is set to "Y" (EXCHANGE all fields on a prompt request), as many of all the other fields used by the program as will fit into the space left in the exchange list will be posted to the exchange list.
The prompting process/function is invoked. It is a simple program and just displays a list of all departments in a pop up window and allows the user to indicate the desired one by selecting it with the cursor. The screen panel that the user is seeing at this point might look like this:

^{INVOICE01 Invoice Inquiry}

^{Company number  . . .  ____ ...................................................................}
^{Dept number . . . . . . . . ____ : DEP01    Departments :}
^{Invoice number  . . . . . _______ : :}
^{:  Dept  Department :}
^{:  Num : Description :}
^{:   001  ADMINISTRATION :}
^{:   002  FINANCE :}
^{:   004  SALES & MARKETING :}
^{:   006  PLANT MAINTENANCE + :}
^{: :}
^F4=Prompt :

The user selects department number 004 (SALES & MARKETING). The prompting function has an EXCHANGE FIELDS(#DEPTNO) OPTION(*ALWAYS) command, so the selected value of department number is posted back onto the exchange list. Remember that when the prompting function was invoked it "extracted" all the things it wanted from the exchange list and then cleared it. At this point then, department number is the only thing on the exchange list.
Control returns to the original program. Since field department number is input capable, the exchange list is examined and the values of all fields known to the original program are mapped back into its storage. In this case, only the department number is mapped back.
Finally the exchange list is cleared and the screen is redisplayed. Since the value of field department number has been changed by the value returned in the exchange list, the resulting display would now look like this:

^{INVOICE01 Invoice Inquiry}

^{Company number . . . _____}
^{Dept number . . . . . 004}
^{Invoice number . . . ________}

^F4=Prompt

The "prompt key cycle" has now completed.

Some further things worth noting about key processing techniques and this example are as follows:

No RDML level coding at all is required in the "invoice inquiry" program to support this processing, it is totally automatic.
The interaction technique conforms to SAA/CUA standards.
Field department number can be prompted on any other screen panel, in any other program, in exactly the same way. This produces a very high level of consistency for "end users" of the application system.
Field department number can even be in a browse list on a screen panel. If prompted, the returned value will be updated into the correct browse list entry before the screen is re-displayed.
If field department number is on a screen panel, but is not input capable, the prompt key can still be used. However, in this case, any values returned in the exchange list are ignored.
Consider an inquiry screen that is showing invoice details to the user. All fields on the screen are protected (i.e., not input capable), but the prompt key is still enabled:

^{INVOICE02 Invoice Inquiry}

^{Company number . . . 003 ACME ENGINEERIN}

^{Dept number . . . . . . 004 SALES & MARKETIN}

^{Invoice number . . . . . 1627487}^{Date of issue . . . . . . 10/10/89}

^{Customer . . . . . . . . . . 152643}^{Talls Hardware Shop}^{121 Any Street}^{Anytown 41828}

^{Product Description SKU Quantity Price}^{0001920 1/4" BOLTS BOX 300 700.45}^{0188734 4" CLOUT HEAD NAILS BOX 200 200.34}^{1102939 ROOFING STRUTS PALLET 2 1107.00}^{0126378 6" GALVANISED GUTTERIN}^{20LENG 10 265.45}

^F4=Prompt

By using the prompt key from this screen, the user might be able to perform the following additional "inquires" (with no extra RDML coding required in the invoice inquiry program) on:

Companies.
Departments.
Other types of invoice inquiries. The same program cannot be invoked recursively by the prompt key. This situation is trapped and the screen redisplayed with an error message.
A calendar. Some sites nominate a "calendar" program as the prompt key processing program for all date fields. This allows the user to select the date required from a "calendar".
Customers.
Products.
SKUs. (Stock taking units).