Prompt sets are the usual way of defining ahead of time a set of inputs for which the user will be prompted; but there is no straightforward way to choose at runtime which prompt set object to use. In some situations, it is useful to be able generate an input dialog box dynamically, based on pieces of information that are not known prior to execution.
I developed an approach that can be used to address this need. Here is an example prompt set with an assortment of various element types.
Figure 1. An example prompt set
The script that processes this prompt set looks like this:
:SET &PromptSet_Name# = "UC0.PROMPT_SET-TEST.PRPT":INC UC0.GENERATE_INPUT_DIALOG.JOBI:INC UC0.PRINT_VARIABLES.JOBI
The include object UC0.GENERATE_INPUT_DIALOG.JOBI does all the work. Behind the scenes, it uses a couple of SEC_SQLI objects to read the details of the prompt set:
(It was necessary to use these VARAs because the :PREP_PROCESS_PROMPTSET command is not able to read all of the details of the prompt set.)
After reading the prompt set details, the JOBI uses these pieces of information to dynamically generate a :BEGINREAD...:ENDREAD block, recreating the prompt set as faithfully as possible.
The dynamically-generated input dialog box looks like this.
Figure 2. A dynamically-generated input dialog box, generated based on the example prompt set in Figure 1. (Multi-select elements displayed as text fields)
The :READ command does not support reading a variable via indirect reference — that is, reading in the value of a variable whose name is set at run time. Because of this, you must modify the JOBI before this will work with your prompt sets.
Near the end of the JOBI there is a :SWITCH block containing the actual :READ commands. Note that there is exactly one :CASE clause and one corresponding :READ command for each variable in the demo prompt set. If you have a prompt set with variables called &APP_NAME# and &SEQ_NUM#, then you’ll need to add these four lines to the :SWITCH block:
: CASE "APP_NAME#": READ &APP_NAME#, &InputCheck#, &Caption#, &Default#, &InputHandling#: CASE "SEQ_NUM#": READ &SEQ_NUM#, &InputCheck#, &Caption#, &Default#, &InputHandling#
: CASE "APP_NAME#": READ &APP_NAME#, &InputCheck#, &Caption#, &Default#, &InputHandling#
: CASE "SEQ_NUM#": READ &SEQ_NUM#, &InputCheck#, &Caption#, &Default#, &InputHandling#
The :READ command does not support display of check box elements. The display of such elements (check box groups and and check box lists) can be customized by setting the value of the variable &Display_MultiSelect_Elements_As#.
If &Display_MultiSelect_Elements_As# is set to text., the two check box elements are displayed as text fields, as In Figure 2 above. A label is inserted above such fields, informing the user of the inputs that are accepted. This behavior is the default if no value is specified for &Display_MultiSelect_Elements_As#.
Figure 3. Multi-select elements displayed as text fields
If &Display_MultiSelect_Elements_As# is set to combo, these two elements are displayed as combo boxes.
Figure 4. Multi-select elements displayed as combo boxes
If &Display_MultiSelect_Elements_As# is set to menu, and these two elements are displayed as combo boxes.
Figure 5. Multi-select elements displayed as menus
Text elements with multi-select enabled are always displayed as ordinary text fields. A label is inserted before the field, indicating that multiple values may be entered, and mentioning the character that should be used to separate different values.
Figure 6. A multi-select text element
There are a few limitations, mostly due to underlying limitations of the :READ command:
The objects are attached. This discussion stems from a questionPhillipPetermann607578 recently asked :Rebuild Prompt - Substitution VARA in ":READ - Command".
Thanks to a helpful suggestion from LeonardOlteanu, I was able to greatly streamline the steps that fetch the details of the prompt set. (This required using some DB-specific SQL though. My SQLIs are written for Oracle. You might need to rewrite some of the XML-specific bits if you use a different DB.)
I also added support for elements with an XML VARA data source. (The results returned by PREP_PROCESS_VAR_XML are all uppercase though. If anyone knows a fix for this, please let me know.) I figured this out. PREP_PROCESS_VAR_XML was working fine, but the JOBI was failing to set the K input handling flag for combo box elements. This has been fixed.
I updated the JOBI again (v5), adding the ability to customize the way multi-select elements (check box groups and and check box lists) are displayed, via the variable &Display_MultiSelect_Elements_As#.