DP4 has two main families of functions for getting input from the user for a specific field. Both sets of functions use and/or set, a considerable number of global variables. There are functions spcific to each data type supported by the DP4 database. The functions ensure that the input value is valid and, when the input is associated to a field on the database,within the range of values allowed for the field. They can also simplify things like resetting the values in a dialog to the initial "default" values, providing pop up lists for a user to select from, and returning focus to the appropriate point if the user inputs a value that additional validation in your code disallows.
The askf_x() functions are used where the user is not allowed to navigate away from the current field. In practice this means they are rarely used.
The inpm_x() functions are used for collecting input in a dialog where the user can roam around the fields with the cursor keys or by clicking with a mouse.
A variable called df_libtype determines certain global behaviours of the DP4 Terminal manager. It is something that should rarely if ever be touched (it can be set by a libmake directive). Basically it is a set of bit flags. Very occasionally, when we think "Wouldn't it be nice if _______ (insert name of function) worked like this,instead of the way we first thought of?". If the answer is yes we use up one of the bits in df_libtype, to enable the new behaviour without upsetting existing programs.
Both families of field input functions store information about the key used to navigate away from the field in the abort_code variable. This is usually, but not always, also the return value from input functions. The return value from input functions should be used in the following way:
The input functions do not necessarily stop and ask for input. If the user presses an OK button or the Enter key to complete a dialog, input into remaining fields in the dialog is skipped. This is done by setting the variable jump to TRUE. The function is still called, in case the data is invalid. If it is the user will not be allowed to close the dialog, and will have to correct the offending value(s). jump is a very important variable, as you have to remember to set it to FALSE if a validation in your code fails and you reset the field number. Failure to set jump FALSE in this situation is a frequent cause of "jump loops", which result in a hung program.
Two more global variables control what input functions do with the initial value passed to them. Usually you will want to display this as the initial value to the user. However you may want to reset the field to the "default" value. This is often, but by no means always, 0,blank etc. Dates and times are often defaulted to the system clock for example.
A field will only be reset to the default value if the corresponding field in the map has the clearfirst property set, and the global variable clearfirst is set to a non zero value (usually 2). In addition the variable range must indicate that this is the first time the field is being visited. Usually range is initialised to 1 at the start of a dialog and DP4 looks after it from then on. It is usual to set clearfirst to 2 when a dialog is being used to insert a new record, and to 0 if it the same dialog is used to amend an existing record.
Two more variables changed and selected tell you something about what a user has done to a field. If you set changed FALSE before calling an input function, and it comes back TRUE then the user changed the value of the field from the initial (but possibly clearfirsted) value presented to him. selected is very obscure, but it is used inside some of the functions supplied as source code, as it can tell you whether certain abort_code values were generated as a result of a function key being pressed, or through some other method. changed is often more trouble than its worth, and certainly should not be relied on for more than one call to an input function (a user might change a value and then change it back again leaving changed TRUE when nothing is different from the initial state).
Finally a variable called scrn_flags can be used to control the display format of input fields, and it also determines what special keys fields respond to. Date fields use scrnd_flags instead. Responding to special keys is discussed in more detail next.