901 - 19 Sep 04

(Windows/ATE) When INFLD displays a message box (typically to report an editing format error), the title of the message box is now taken from the 000,001 entry of the SYS:APPMSG.xxx file (where xxx is your language definition, e.g. "USA", "CDN", etc.) If the file or entry is not defined, then it continues to use "INFLD".

897 - 10 Aug 04

(INFLD GUI) The handling of fixed pitch fonts in the GUI version of INFLD has been improved somewhat. Unlike proportional fonts (which we only scale vertically and let the horizontal size default based on the display aspect ratio and judgment of the font mapper), fixed pitch fonts can be scaled both vertically and horizontally. We use this to ability to try to generate a font that fits within an INFLD edit box in such a way that the box gets filled up when you get to the maximum number of allowed characters for that field. (With proportional fonts, this is out of the question.) Note that because fixed pitch fonts are currently scaled to an integer width in pixels, as a practical matter, the maximum number of characters is not going to exactly fill the box. But it should be reasonably close. If you cannot stand that imperfection, you might have to just give up on the GUI version of INFLD and continue to use the text version.

Note that along with the scaling improvements, we've reduced the degree of automatic expansion of small field lengths. Previously, 1 and 2 character fields were expanded by one character (to allow for font size irregularities.) When the fixed pitch option is set, we now only expand single character fields to 2 column (mainly because the edit window border reduces the available size of the field by so much that a single character field is just too skinny to look good.)

896 - 20 July 2004

(WINDOWS/ATE) The INFLD combo box (activated when you have a "normal" setdef list and |G) can now accommodate about 1200 bytes of options in the setdef parameter (up from 512 previously). For choosing from lists longer than that, you might as well just use PCKLST or XTREE.

895 - 20 July 2004

(WINDOWS/ATE) GUI version of INFLD now obeys the infclr settings. Previously, while editing, it always used the standard Windows colors. If you want to keep that behavior, set EFCLR and EBCLR to -2, either in the infclr parameter passed to INFLD, or in the INI.CLR file. 

(WINDOWS/ATE) A new option to "use fixed pitch font in edit boxes" has been added to the Misc Settings dialog. When set, INFLD uses the currently defined fixed pitch font (see Settings...Fonts) and attempts to scale it slightly down to fit in the edit window better. It does not completely eliminate the complaint that the size of the edit window does not perfectly match the number of characters which are allowed, but now the edit windows will more or less uniformly appear to have room for one more character than is allowed. (This is necessary, otherwise Windows will not display that last character without scrolling the field.) Note that when you edit the field it will be redisplayed using the defined "proportional" font. If you do not like the drastic change between the fixed pitch (in edit mode) and the proportional pitch (upon display), then you can always set the "proportional font" to the same as the fixed pitch font, in which case all of the GUI controls will use it.

Update: Build 881 - 14 Apr 2004

INFLD supports a new mechanism for encoding pseudo-function keys which works better in heterogeneous environments involving ATE or the Windows control implementation of INFLD. The new scheme also allows for an unlimited range of virtual function keys (whereas the previous scheme only really supported F1 through F127.) The new encoding format is:

CHR(7) + CHR(250) + FNUM$ + "."

where FNUM$ is the string representation of the function key number (e.g. "1" for F1, "793" for F793). Since the number has a variable length, a terminator character is required. In the above example we use a period, but any non-numeric character will work.

As an example, if you want to set up an INFLD field so that when you click on it, it acts like a virtual F122 (i.e. returning exitcode -122), then you could set the hlpidx string as follows:

hlpidx = chr(127) + chr(7) + chr(250) + "122."

As of Build 883, this syntax as been changed to:

hlpidx = chr(126) + chr(7) + chr(250) + "122."

Note that this takes advantage of an INFLD feature relating to hlpidx. The leading CHR(127) is needed to tell INFLD that what follows is a mouse click string.

Update: Build 882 - 18 Apr 2004

In INFLD, when inxctl is a one byte string and the use transmits the new pseudo function key sequence, inxctl will return 250. (This allows these sequences to be distinguished from the normal IFX function sequences, which set inxctl to 7.) This distinction is useful when the new pseudo-function key sequences are used to encode mouse clicks, thus avoiding the need to start the mouse pseudo-function key codes at some offset to avoid confusion over F-key generated function codes.

The INFLD edit control (|G) now uses the type sequence |K to determine whether to adopt Windows-style or AMOS-style conventions whenever the two are in conflict. For example, without |K, the initial input mode is overwrite; with |K it is insert. (You can now use the Insert key to toggle between insert and overwrite mode.) Without |K, the Home key is considered a field exit key (returning exitcode 9 if type 9 is specified); with |K, Home just moves the cursor to the start of the field (but you can use Ctrl+Home to get the exitcode effect.

Update: Build 885 - 03 May 2004

INFLD now uses a date-time "picker" control for date (type D) and time (type t) fields when in GUI (type |G) mode. Note the following idiosyncrasies of this control:

• The date picker takes up more space than the traditional MMDDYY (or DDMMYY) format of date entry, so the control is automatically elongated by a few extra columns. Although this might possibly overwrite something to the right of the control, the effect is only temporary, since as soon as you exit from the control, it is redisplayed using the normal size and format.

• If you set xmin to 0, the date picker control will include a checkbox which the user can uncheck to indicate no date. Otherwise there is no way to enter a blank (or invalid) date.

• The left and right arrow keys will move between the sub-fields of the date or time. If you want to pass these arrow keys to INFLD (to be treated as possible field exit keys), you will have to hold down the Shift or Ctrl buttons while hitting the left/right arrows.

• To edit each sub-field, you can use the number keys, or the numpad +/- key. In the case of the time control, you can also increment/decrement it using the up/down buttons which will be appended to right edge of the field.

Update: Build 885.2 - 06 May 2004

INFLD/GUI keyboard handling refinements:

• Alt+Down+Arrow may now be used as a keyboard shortcut to display the calendar in the date picker.

• Up/Down+Arrow may now be used, in addition to the numeric keypad Plus and Minus keys to increment/decrement the currently selected sub-field (in the date picker).

• Shift+Tab now acts like UpArrow when type 3 is specified (returning exitcode 3).

Update: Build 892 - 10 Jun 2004

(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 idiosyncrasies 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 radio buttons.

• 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 AUI_CONTROL, or AG_CONTROL|topic=Edit GUI Control), 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 number of a control previously created with AUI_CONTROL, and row and col are ignored. If V > 1, then it is treated as the control ID number of a group box to which the checkbox or radio button belongs, and the row and col parameters are offset within the group box.) 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 radio button, 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 would not then be clear which other button in the group should be toggled on.) (Because it is a radio button and not a checkbox, only one button in the group, at most will be checked at one time.) Considering this idiosyncrasy of radio buttons, they do not work that well as INFLD fields unless your users are prepared to use the mouse to jump to the next non-radio button 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 radio buttons without leaving the last one selected.) Thus, it may make more sense to treat radio buttons 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.)

Update: Build 892.4 - 17 Jun 2004

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).

Update: Build 893 - 24 Jun 2004

(Windows/ATE) Checkboxes created with INFLD now have the MBF_UNPROTECTED flag set so they can be deleted with Tab(-1,10) (more like static text than like regular buttons).

Update: Build 894 - 28 June 2004

(Windows/ATE) Several improvements have been made to checkboxes (now type ||c), allowing them to be handled nearly like Y/N fields. Contrary to the recommendations set out under edit 892, our latest recommendation is to either use INFLD for all aspects of checkbox implementation (creation, display, editing), or use AUI_CONTROL for all aspects. You can mix the two (i.e. create the checkbox using AUI_CONTROL and edit it with INFLD, but this is likely to cause confusion.) If you use the AUI_CONTROL method, then your program does not need to monitor the user while editing the checkboxes; you only need to query the checkboxes at some later time to see which ones are checked. In contrast, if you use the INFLD method, then you should implement an exitcode sequence allowing the user to go directly to a checkbox field by clicking on it, and treat it almost just like a normal Y/N field.

The main differences between Y/N fields and checkboxes are:

• The text label of the checkbox is an integral part of the control. You must pass the label in the setdef parameter, and set the xmax value large enough to accommodate the label (instead of just 1 which would be typical for Y/N fields.)

• The user toggles the checkmark with the mouse or the space bar.

• The OFCLR/OBCLR fields in infclr are now used to set the color of the checkbox label text when displaying or redisplaying the checkbox.

Note that, at this time, we are only encouraging the use of INFLD for checkboxes, and not radio buttons. In most cases, a single combo box (see 892) is much cleaner to simpler than a series of radio buttons. If you insist on radio buttons, it is probably best to just implement them using the AUI_CONTROL method.