The sequence "VK_x{r,d}F### allows you to generate a wide range of exitcode values in response to various click events for the associated control.
The optional "{r,d}" may be replaced with "", "r", "d", or "rd" (to enable special handling for right click and/or double click events), and "###" is replaced by a numeric string in the range of 1 to 999999 (defining the exitcode value). The actual byte sequence transmitted will be chr(7) + chr(250), followed by the string of digits (corresponding to the ###), and terminated with a period ("."). You can input and interpret such stings yourself using a character-level input routine (such as GET, ACCEPN or the GETKEY function), but many higher level A-Shell routines which wait on operator input events (e.g. INFLD, XTREE, XTEXT, EVENTWAIT, etc.) will do the translation for you automatically, returning the corresponding numeric exitcode value. The following table of examples will help clarify:
Code String |
Click Event |
Raw Byte Sequence |
Exitcode |
Notes |
---|---|---|---|---|
VK_xF123 |
Left Click |
chr(7),chr(250),"123." |
-123 |
Left click exitcodes are negative |
|
Right Click |
chr(7),chr(250),"123." |
-123 |
Since no "r" in code string, right click same as left |
VK_xrF42 |
Left Click |
chr(7),chr(250),"42." |
-42 |
Note: ### values < 100 not recommended since they may overlap other pre-defined exitcode values |
|
Right Click |
chr(7),chr(250),"-42." |
42 |
"r" present; right click sequence contains "-" but exitcode is positive |
|
Left DblClick |
chr(7),chr(250),"42.",chr(7), |
-42,-42 |
"d" not present; double click is same as 2 regular clicks |
VK_xrdF9999 |
Left Click |
chr(7),chr(250),"9999." |
-9999 |
|
|
Right Click |
chr(7),chr(250),"-9999." |
9999 |
|
|
Left DblClick |
chr(7),chr(250),"9999.", |
-9999, |
First click generates normal sequence; second (double) click generates extended version with extra "000" (x1000). See comments. |
|
Right DblClick |
chr(7),chr(250),"-9999.", |
9999, |
Same as left double click except with positive values. |
Comments
Double-click handling is particularly tricky, since by the time the second click is recognized as being part of a double-click sequence, the first click has already been responded to (by generating the corresponding single-click sequence and exitcode). So in order for this to make sense, the application's response to a double-click has to be a logical extension or continuation of its response to a single click. For example, in a screen full of clickable appointment indicators, the single click event might result in more information being displayed about the appointment, while the double click might launch a dialog to allow editing of the appointment attributes. By contrast, if the single clicked caused the application to change its context, it might then no longer be in a position to properly respond to the double click exitcode.