A-Shell Development History

899,5.1

(Windows/ATE) Fix a GPF problem related to certain kinds of INFLD forms (TYPE f).

899,5.2

New INFLD TYPE codes:

 

899,5.

(WINDOWS/ATE) INFLD "self service combo box" - if SETDEF = "..." then when the user clicks on the down arrow to activate the drop down list, the field exits, returning EXITCODE 29.

899,5.4 09 Sep 04

ATE: ZTERM label window sequence (chr(27);chr(13);"title";chr(0)) now sets both the normal and minimized window titles.

899,4.1

(Windows/ATE) Reverse INFLD TYPEs |R and ||R. |R now causes the field to be destroyed on exit (clearing the way for the app to redisplay it using non-GUI technology), which is closer to the way |R worked before the 899-3 change. ||R leaves the field as-is on exit (i.e. without redisplaying it using a static or other control type). This was thought to be a useful technique for allowing certain advanced INFLD types (combo boxes, date pickers) to maintain their visual form even when inactive, but it is probably now superceded by the expanded implementation of ||C (see next).

899,4.2

(Windows/ATE) INFLD TYPE ||C now also applies to date pickers and time pickers, in the same way as to combo boxes (see 899-2 below). In other words, without ||C, a GUI date field (TYPE D|G) will appear in the form of a date picker control (with a dropdown button which opens up a calendar) while editing, and then revert to an ordinary static text control on exit from editing mode (or when displayed with OPCODE 2). WITH ||C, it appears as a date picker control at all times.

Note that it makes little sense to use ||C unless you are also implementing mouse-click sequences such that when the user clicks on one of these controls, your app can sense the click, interrupt the current field and jump to edit the click-on field.

899,4.3

(Windows/ATE) Fix a problem with INFLD TYPE |E (see 899-3) disabling the click action on the inactive control.

899,4.4

(Windows/ATE) TAB(-10,20) now supports 5 additional optional params:

?TAB(-10, 20);OP;", ";BTNID;", ";TXT;", ";STATE;", ";TYPE;", ";CMD;", ";FUNC;", ";SROW;", ";SCOL;", ";EROW;", ";ECOL;", ";FGC;", ";BGC;", ";STYLE;", ";SCALE;", ";FACE;", ";TIP;", ";PARENTID;", ";RTNFLAG;", ";CLASS;", ";STYLE;", ";STYLEX;chr(127);

PARENTID may be used to make the current control a child of the specified control. This and RTNFLAG are primarily for internal use and should be set to 0 by an application. CLASS, STYLE, and STYLEX provide a way to specify control types and style options that are not covered by the TYPE parameter. These are also mainly used internally but might be interest to programmers familiar with the Windows CreateWindowEx() API function.

899,4.5

XCALL MIAMEX,118 (get/set stream position) now supports an optional argument to specify an index:

XCALL MIAMEX,118,CH,OP,POS{,FILIDX}

If specified, and OP=1 (set stream position), then POS is interpreted as the desired line number within the file (starting at 1) rather than the byte offset within the file. If FILIDX does not reference a valid index, the operation will fail, returning -1 in POS.

See the next item (XTREE) for information on creating the index.

899,4.6

XCALL XTREE now supports an additional optional argument in conjunction with multi-select file mode to create an index into the file, of the type that can be used with the new MIAMEX,118 operation (see above).. The argument (FILIDX) must be mapped as B,4 and added after the XTRCTL parameter:

xcall XTREE, SROW, SCOL, ANSWER, ARRAY, ADDCNT, COLDEF, EXITCODE, EROW, ECOL, FLAGS, FILE, MMOCLR, XTRCTL, FILIDX

The index into the file is created while the file is being loaded, so there is no significant overhead other than the memory allocated. The FILIDX parameter is returned as a handle to the actual index, which is kept in dynamically allocated memory. It can be passed to the enhanced MIAMEX,118 function (see above) to position the file pointer of an open sequential file to the start of a specified row within the file. This is primarily useful with the multi-select file mode, because in that case, the selection information is returned as an array of one byte strings, each indicating whether the corresponding row was selected. In the array case, you can easily access the array data directly, but in the file case, in order to access a selected row, you would have to read through the file from the beginning, counting the rows, which is not very effcient or convenient.

See the updated XTRFIL.BP sample program for an example of using this technique.

Note that you should only use one FILIDX variable within a program, and you should not modify its value. If you follow this guideline, A-Shell will automatically free up the memory used by the index for each new XTREE call and when the program ends.

899,4.7

(Windows/ATE) XTREE.SBR now supports more than one XTREE instance open at the same time. You specify which instance you are referencing by setting the XTR'CTLNO field in the XTRCTL parameter (to 0, 1, or 2). Note that in order to have more than one XTREE visible, you will have to use the XTF'MODELESS option so that the control is not deleted when you exit from it.

A new sample program, XTRA4.BP (see the latest XTREE5.ZIP package on the beta page) provides a rudimentary demonstration of using two XTREE controls at the same time.

899.4.8

(Windows/ATE) INFLD's "Invalid Input" message (011,010 in sbrmsg.xxx) now supports a trailing "%s" which will be replaced by the SETDEF pattern if in GUI mode but not already using a combo box. This can be handy when you use SETDEF as a means of enforcing a pattern, since it permits the user to see what the pattern is (rather than just being told "Invalid Input"). The standard sbrmsg.xxx files have not been updated, but if you are interested in this feature, just add "%s" to the end of yours, i.e. "011,010,Invalid Input %s".

899,4.9

(Windows/ATE) INFLD's time picker control (TYPE t|G) now uses a fixed editing and display width wide enough to accommodate HH:MM:SS PM. Note, however, that the returned time will be in HH:MM:SS (military format). This is not strictly compatible with text mode, where the XMAX parameter can limit the entry to, say, HH:MM format.

899.3.1

(Windows/ATE) Fix a conflict between XTREE and dialog boxes in which the dialog box would not retain the focus (causing selected items to appear gray instead of blue, and keyboard characters to not work as expected.)

899.3.2

(Windows/ATE) New INFLD TYPE ||R is similar to |R (prevent redisplay) but instead causes the edit control to be destroyed on exit from edit mode. This actually makes more sense than |R if you plan to redisplay the field yourself, especially if you plan to redisplay it using normal text.

899.3.3

(Windows/ATE) New INFLD TYPE |E causes the display form of the field (either on exit from edit mode or when using OPCODE 2) to be based on an edit control rather than a static text control. The difference is subtle but edit controls have a slightly deeper border. Also, as an edit control it is subject to the "Force standard colors in edit boxes" option on the Misc Settings dialog.

899.3.4

(Windows/ATE) Fix a problem with closing a dialog via the "X" if the dialog contained an XTREE control. Clicking the dialog "X" no longer directly closes the dialog; it only transmits an ESC into the keyboard buffer, leaving it to the application to close the dialog using MIAMEX,119 opcode 3.

899.2.1

(Windows/ATE) New INFLD TYPE ||C forces the creation of a combo box when a field is being displayed (either after editing or with OPCODE 2). This is useful combo boxes (automatically created by SETDEF) when you want to them to retain the combo box appearance even when the field is not active. Note that it is important that you set up a mouse click sequence (in HLPIDX) when you use this technique, so that when the user clicks on the combo box, your application is able to respond.

899.1.2

COMPIL and OCMPIL (not COMPLP) now compile TPRINT and DPRINT statements as if they were ordinary PRINT statements if /X not specified and provided that OPTIONS=STRICT is not set. This "feature" is hoped to be useful to developers whose programs may have sections intended to run only under A-Shell and other sections intended to run under AMOS, and who want to take advantage of TPRINT and DPRINT. Otherwise, even though the TPRINT and DPRINT statements might never get executed, they would fail to compile under AMOS. Now, you can compile such a program under A-Shell and move the .RUN to AMOS for execution.

Note that since TPRINT, DPRINT, and PRINT are rather similar, it might even be that you can use the same source code under A-Shell and AMOS without having to use a condition (IF AMOS THEN ... ELSE ...).

899.1.3

Dialog boxes can now support a "system menu" (aka the "X" button to close the dialog). To enable the dialog system menu, add MBF'SYSMENU to MBF'DIALOG when creating the dialog box. (MBF'SYSMENU is defined as 256 in edit 92 of ashell.bsi; this is also the same as MBF'BITMAP, which is being recycled because it doesn't apply to dialogs.) If the system menu is enabled and the operator uses it to close the dialog, an ESCAPE character (ASCII 27) will be placed into the keyboard buffer. If you enable the system menu, you must check for the ESCAPE, for two reasons. First, +if the user closes the dialog and you don't check for the ESCAPE, then your program won't realize that the dialog has been closed, which probably cause your program to hang. Second, even if the user closes the dialog via the system menu, your program must still call the MIAMEX,119 function with opcode 3 to properly close the dialog and free up all of the internal resources associated with it.

899.1.4

The ISAMPLUS UPDATE'RECORD statement now generates a Basic error #231 instead of merely returning status -3 when there is an error in updating one of the index files. This could potentially interrupt programs which were already checking for this condition, but given that a similar error in the GET statement generates the same error, and that it is highly unlikely that there is any appropriate response to such a condition other than rebuilding/verifying the index(es), it seems appropriate to generate a Basic error here (that can't be ignored).

899.1.1

TREE.SBR, when in multi-select mode, now supports ^A to select all and ^B to clear all. (This makes it possible to create "Select All" and "Clear All" buttons that are separate from XTREE but associated with it (perhaps by being within the same dialog box.)

XTREE.SBR now also allows the use of END and HOME keys to move to the last or first position in the array. If these keys are allowed exit keys, then you must use them with the SHIFT or CONTROL key in order to get the exit key action.

XTRA2.BP sample program enhanced to illustrate this now (select the dialog and multi-select options).

899.1.1

Modal dialogs now support the same color logic relative to TPRINT, DPRINT, INFLD, MIAMEX, etc. as the main A-Shell window does.

(WINDOWS.ATE) Implement the ability for applications to create modal dialogs on the fly, using XCALL MIAMEX,MX'WINCTL (aka 119) with new control type MBF'DIALOG. (The [91] update to ashell.bsi, contained along with updates of the sample programs in XTREE2.ZIP on the beta page, defines MBF'DIALOG as equal to 536870912.)

A "modal" dialog is one that holds on to the keyboard focus, making it impossible to type in any other window owned by the current application, until the modal dialog is closed. You can, however, drag the dialog around, access the main A-Shell menu bar, and even pop up nested modal dialogs.

Once a modal dialog is opened with A-Shell, any subsequently created controls (buttons, static text, edit prompts, etc.) will be owned by the dialog box, and their coordinates will be taken as relative to the dialog box. Ordinary text output (e.g. PRINT statements) will ignore the dialog box and appear in the main A-Shell window. (In other words, you can only place Windows control-objects within these dialog boxes.)

When creating a dialog box, you should save the control ID parameter that is returned by XCALL MIAMEX, so that it can be used later with opcode 3 to delete the dialog box. Deleting the dialog box will automatically delete the controls within it.

The XTRA2.BP and XTRA3.BP (XTREE) sample programs have been updated to illustrate a primitive use of dialog boxes. XTRA2 wraps the XTREE control within a dialog box, while XTRA3 allows you to pop up nested dummy dialogs on top of whatever is currently on the display.