In order to implement the effect of allowing a user to be able to click on a field in order to edit it (as is typical in Windows forms), you need some way of telling your application that the click event has happened. The recommended way to do this is to encode unique high-numbered pseudo-function-key exit codes with each field. The format for this is:

Chr(7) + chr(250) + "###."

In the above example, the ### characters should be replaced with the number of the pseudo-function key, for example, “231.” for function key 231. Since function keys normally set exitcode to the negative of the function key number, this would cause the current INFLD operation to exit with exitcode -231.

To further clarify with an example, lets say you have a screen with 20 fields, each of which uses the above technique to associate itself with a pseudo-function key 201 through 220. If the user is currently editing field one and then she clicks on field fifteen, the INFLD call to edit field 1 will return exitcode -215, allowing your program to then do any post-field processing you desire before jumping to the routine to edit field fifteen. Obviously this does involve some programming effort, but if systematic logic is used for field editing, it is usually not too hard to add this kind of logic to an existing program.

If hlpidx contains both a tool tip and a mouse click string, then the tool tip must be in the first position, followed by a chr(126) delimiter character, and then the mouse click string, e.g.:

hlpidx=">Tool tip first" + chr(126) + Chr(7) + chr(250) + "213."

The sample syntax for the mouse click string above suggested a three-digit number, but in fact, they can range from one to six digits, thus allowing you, if desired, to assign a unique code to every field in your entire application.

When mouse cursor reporting is active, INFLD treats a mouse click outside of the field as an exit condition, returning exitcode -47. You can then retrieve further information about the last click by calling MX_MCRS (see next).