Reviewed August 2010

Uncoupled Mode

In the normal mode, the list is coupled to the edit control. Even though the application is responsible for supplying the data to build the list, the application only needs to communicate with INFLD. It is INFLD’s responsibility to create the list control, update it, give it the focus, capture clicks, etc. But in the uncoupled mode, the application takes charge of the list control (typically using XTREE, but theoretically anything it likes), and INFLD is only responsible for returning the related exitcodes. No special type codes are required for this mode. Instead, when the application receives exitcode 30 or 31, instead of building the list data in the setdef parameter and returning to INFLD, it must build and display the list control itself. When returning to INFLD to allow the user to continue typing, the setdef parameter should be left blank (which will prevent INFLD from trying to create/display the list itself).

In addition to responding to exitcodes 30 and 31, the application should also respond to whatever exitcode it assigned to the list control that it builds. (For example, in the case of XTREE, via XTR.KBDSTR.) When the user clicks on the list control built and displayed by the application, the natural response would be for the application to put the focus on that list control, allowing the user to scroll among the choices with the arrow keys and select one by hitting Enter. The application must also respond to the exitcode returned from the list control (i.e. XTREE), so that it can allow the user to return to the edit field either by up-arrowing out of the list control, or clicking directly on the edit control.

Uncoupled mode allows the application maximum flexibility, but requires considerably more programming effort. The only benefit being derived from INFLD in this case is the auto-complete time-out mechanism. (In comparison, the normal field time-out is too simple-minded to work well in this situation.)

Auto-Complete with Self-Service Combo Box

In this variation, the control starts out as a combo box rather than an edit control. As in the normal case of a Self Service Combo Box, you must set setdef="…" to activate it, and clicking on the drop-down button returns exitcode 29. Although the application can do whatever it wants with that exitcode, the normal plan would be to respond to it just like you would to exitcode 30 (i.e. build a list by passing a properly formatted setdef backto INFLD.) Note that on return to INFLD, the control would then change from a combo to an edit box, and from that point would act like the normal Auto-Complete case.

Auto-Complete with Coded Lists

Auto-Complete can be combined with Coded Lists (||L) rather than standard setdef lists of complete entries, although the main effect is only felt on the final exit from the field. In the interim exits (with exitcode 30/31), the raw field contents will be returned to the application (since that’s what the auto-complete list would be based on), and the application can return either the coded or raw field contents on re-entry. (INFLD will first try to convert the entry string as if it were a coded value, but if that fails, uses it as is.) In almost all cases, you would want to also specify the||s (list matching optional), unless you planned to fill your list with all of the valid possibilities. (In that case, it isn’t clear how Auto-Complete would really be of any advantage, vs. just using a regular combo box.)