View Source

Since prompt key processing programs are user coded RDML programs, they can be very flexible and handle just about any situation.

An example of a more complex prompt key, processing program might involve prompting something like a "customer number".

When invoked, it might initially present a pop-up window that looks like this:

^{INVOICE01 Invoice Inquiry}

^{Company number . . .}^{Dept number . . . . . . . .}^{Invoice number . . . . .}^{Customer number . . .}

^{...................................................................................................}^{: CUST01 Customer Number Search :}^{: Select type of search required and press enter :}^{: :}^{: 1. By name :}^{: 2. By outstanding orders :}^{: 3. By city of residence :}^{: 4. By post / zip code :}^{: :}^{: F12=Cancel F14=Msgs :}^{: :}^{:..................................................................................................:}

^F4=Prompt

The actual processing that this program performs is immaterial. What is important is that you understand the following points about using it:

That it can be viewed like a "black box". It is invoked and it returns a customer number. How it does this does not matter very much to the routine which invoked it.
That it produces a very consistent and reliable user interface. Any screen panel that requests that a user input a customer number can have the search routine automatically invoked without coding one extra line of code. You would have to take positive steps to be inconsistent.
That routines that display a customer number (i.e., it is not input capable on the screen panel) still have the ability to invoke the prompt routine automatically. Information exchanged back by the prompting program is ignored in this case.
That it does not have to use pop-up windows. Normal DISPLAY and REQUEST commands can be used, and may be more suitable, in some cases. The main reason for using pop up windows is for SAA/CUA compliance.