Users expect not to have to manually key in all the data entry fields in a dialog, but to be able to bring up a list of the possible choices for each field in a pop-up window (opening the list box part of a combo box in Windowsese). The pick_record() and pick_list() functions are desgined to help you provide this kind of facility in your own programs. A range of records can be scanned through by the user, where only a few record details are displayed at one time. In the DP4 API, this type of pop up window is usually called Prompt.
In fact pick_record() and pick_list() are not just useful inside dialogs. It is possible to combine the windows used by these functions with a menu bar, so that a whole prorgam is controlled from a call to pick_record() or pick_list(). An example of this is the BROWSER utility.
pick_record() solves the problem of using a list box with a big database. Windows list boxes are usually populated with every single possible option. On a big database this can use a prohibitive amount of time and memory. pick_record() only reads enough records to populate a listbox a page at a time. Both pick_record() and pick_list() can also dynamically update other information on screen as the user moves round the list of choices.
These functions have a lot of parameters, and can be rather intimidating for a novice user of DP4. They are well worth persevering with however. Both are provided in source code form, so you can adapt them if required.
The map_glue() function usually comes in handy when creating the callback functions needed by pick_record() and pick_list().
In 4.6xx You can inform the user that prompt is available for a field by setting (with MAPEDIT) the prompt flag for the edit control used for entering the field . This causes the control to appear with a prompt button next to it. (This is a button with a downward pointing arrow on it). Clicking the mouse on the button while the program is calling the fields input function will cause the input function to return. The input function returns 0 and the field number is set to the next input field, but the value in abort_code is set to SPACE_BAR (you may like to add your own definition: #define PROMPT_REQUESTED SPACE_BAR). You arrange for your validation code to test for this value and brong up the prompt window when it is detected. If the use selects a record form the list, then you set the input field to the appropriate value and resume processing at the next input field. If the user cancels the window then you should reset the field number and ask for input again.
In 4.5xx you can provide a similar arrow next to an input field to indicate prompt is available by pressing Alt+P with the caret in the appropriate position when in the text entry mode of the DP4 MAPEDIT program. However you have to also set the flag PROMPT_AVAILABLE in scrn_flags or scrnd_flags.
Users can also request prompt by pressing a key that has been programmed as the "prompt key" using the keyboard customisation option of DFSETUP. In the default configuration pressing <Ctrl+P> generates this key.
If the PROMPT_AVAILABLE flag is set in scrn_flags, but you haven't code prompt for the field, pressing <Ctrl+P>, or clicking the Prompt button, will move to the next field. This is confusing for the user. This means that if some fields have prompt, and others don't you could be faced with having to constantly change the value of scrn_flags. To avoid this the inpm_x() functions actually have two variants: inpm_x() is the normal version, used for fields with prompt (or without prompt if scrn_flags does not have PROMPT_AVAILABLE set), and inpm_x_np(), which are used for fields without prompt in programs where scrn_flags has PROMPT_AVAILABLE set.