892.4.1
INFLD now implements fields which have a "normal" SETDEF parameter (containing a list of allowed entries, e.g. ",red,blue,green,purple,,") as combo boxes. User can type or select choice from drop-down box. As before, to allow an empty field, add TYPE O (for optional).
892.4.2
Cleanup various problems with the new INFLD checkboxes.
892.4.3
Eliminate dependency on Windows API function FlashWindowEx, which is not available under NT4 and W95. Problem was introduced in edit 880.
892.4.4
Cleanup various problems with GUI version of INFLD and fields with TYPE ? and/or timer displays.
892.0.1
(Windows/ATE) Checkboxes and radio buttons can now be created and accessed by INFLD similarly to other field types. (In particular, checkboxes correspond well to Y/N fields.) The TYPE code for checkboxes is "|c" and for radio buttons is "|b" (vertical bar followed by a lower case "c" or "b"). If combined with TYPE Y, the field will treat a checked box as equivalent to the single character affirmative (Y, S, O, etc.) for the current language definition, and an empty box as the single character negative (N). Otherwise, a checked box will correspond to a "1" and an unchecked box to a "0".
Note the following ideosyncracies of checkboxes and radio buttons as INFLD field types:
| • | Checkboxes and radio buttons combine a text field with a square or round box. Although other fields may also associate an edit control with a text prompt, in all other cases, INFLD does not concern itself with the text prompt (which much be displayed via a separate operation). When a particular checkbox or radio button is being edited by INFLD, the corresponding text will be highlighted via a dotted line, giving the operator a visual indication of what field they are on. (There is no cursor for checkboxes and radio buttons.) |
| • | Because of this association between the text and the box or button, if you want to use INFLD to create the control, you must supply the text string (label or prompt) in the SETDEF parameter. (SETDEF does not otherwise apply to these two field types.) (This is not to be taken as a recommendation that you use INFLD to CREATE checkboxes and radiobuttons; see item D below for recommendation on creating them.) |
| • | In contrast to the case with other field types, in which the field becomes an editable control when it has the focus and is converted back to a static/sunken text control when not being edited, checkboxes and radio buttons remain the same whether they have the focus or not. The only visible difference when they have the focus is the dotted outline described above. |
| • | Because of the above, it is typical for checkbox and radio button fields to be created at the same time that your program normally creates the data entry form background. You can create them for display purposes either using MIAMEX,119, or TAB(-10,20), or INFLD. Once created, when you want to edit the field, INFLD will locate the existing control, if it exists, by looking at the ROW, COL, and V parameters. (If V is < 0, it is taken as the actual control ID # of a control previously created with XCALL MIAMEX,119, and ROW and COL are ignored. If V > 1, then it is treated as the control ID # of a groupbox to which the checkbox or radio button belongs, and the ROW and COL parameters are offset within the groupbox.) Unless V identifies the control directly, the existing controls are scanned to find one which has the same starting row/col, or the same ending row/col. The point of comparing just the starting or just the ending position is that after having created the checkbox/radio button control, you may want to treat it like Y/N field, in which case you would probably be specifying a field of size 1 (even though the full control will be several columns wide due to the text component.) |
| • | When INFLD is operating on a checkbox (and the corresponding text is highlighted), you can toggle the check status with the space bar, or by clicking with the mouse. You can use ENTER to exit, or any of the other field exit keys which you've enabled according to the normal INFLD rules. |
| • | When INFLD is operating on a radiobutton, the button that has the focus will automatically be selected (as if you had clicked it with the mouse.) You cannot toggle the button with the spacebar (partly because it wouldn't then be clear which other button in the group should be toggled on.) (Because it is a radiobutton and not a checkbox, only one button in the group, at most will be checked at one time.) Considering this ideosyncracy of radiobuttons, they don't work that well as INFLD fields unless your users are prepared to use the mouse to jump to the next non-radiobutton field. (Otherwise, unless you enable a specific exitcode to jump from the current button to the next group of controls, there would be no way for the operator to keyboard through a group of radiobuttons without leaving the last one selected.) Thus, it may make more sense to treat radiobuttons more like pushbuttons, i.e., as controls that are not operated on directly by INFLD but instead are available for the user to click on at will, with the program querying them before processing the screen data. |
When treating checkboxes and radio buttons like normal INFLD fields, there may be some confusion over the following similar situations:
| • | While within an INFLD call targeting a specific checkbox or radio button, the field will visibly maintain the focus and all keyboard will be filtered through the control. (The result is that other than space bar and defined exit keys, any other keys will probably be ignored.) Clicking on another field may or may not cause the current field to lose focus, depending on various factors. |
| • | If you click on a checkbox or radio button while another INFLD field is active, unless the clicked-on control is set up to transmit an exitcode which will cause the currently active field to exit and the program to jump to the just-clicked field, although the click operation will change the checked status of the checkbox or radio button, the clicked-on control will not retain the focus. Instead, the focus will revert back to whatever field was previously doing input. The point of this is that if you choose not to use INFLD to individually edit your checkboxes, you can use a single generic input routine which just waits for you to exit the current screen (presumably by clicking on a button or entering a special code or key). Clicking on individual boxes in this case will change the status of the checkboxes, but not interrupt the current input operation. (You can query the checkboxes or their control variables all at once when you decide to leave or update the screen.) |
892.0.2
(ATE) The standard INI file for ATE is now MIAME.INI and not ATE.INI. This seems less confusing for those that are using both ATE and A-Shell/Windows.
892.0.3
(ATE) The name of the settings (.ASH) file now matches the ATE configuration name. For example, if you create an ATE configuration called MYAPP, then it will look for its settings (colors, window size, etc.) in MYAPP.ASH in the base directory where ATE was installed. HOWEVER, if MYAPP.ASH does not exist, it will use DEFAULT.ASH (as will A-Shell/Windows now). This allows you to share settings between configurations, or not, depending on your preference.
892.0.4
(ATE) The "Open Local Session" option no longer complains about demo mode if ATE is licensed on the server.
892.0.5
DERR.SBR (display error message, often aliased to ERRMSG) now uses a Windows-style message box if GUI support is available.
