923.3.1
(WINDOWS/ATE) Define new CSTATE flag which can be added to BTST_CHANGE when using opcode 2 to change the attributes of a control, so that only the text is considered. This eliminates the 'flash' that might otherwise appear, particularly when updating the title bar of a dialog. The flag is defined in ASHELL.DEF as:
define MBST_TEXTONLY= &h00000200 ! [115] change text only (512)
923.3.2
(WINDOWS/ATE) INFLD no longer deletes and recreates the control when outputting data using OPCODE 2. This should reduce the amount of screen flash when display many fields at a time.
923.3.3
(WINDOWS/ATE) Fix a problem in XCALL HOSTEX in which the reverse channel would be unnecessarily closed and not re-established when the XCALL returns.
923.2.1
(WINDOWS/ATE) Fix a bug causing characters with ASCII values 128-255 to be stripped when sending them from the workstation back to the server. This was mostly noticeable with INFLD, where the server could preload a field and display it with high-bit characters, but they would disappear when saving the updated field on the server.
923.3.2
(WINDOWS/ATE) Define a new virtual symbolic key string, "VK_NULL", that does nothing. The main use for this would be to allow a tooltip to be associated with a static text control, which is only allowed if the control has a key-click action.
923.3.3
Fix a newly introduced bug in which the compiler would complain about unmapped control variables used in a FOR / NEXT statement even if /M was not used. (Not that we recommend ever compiling without /M, but if you are so imprudent as to do so, it probably shouldn't complain then about unmapped variables.)
923.3.4
(WINDOWS/ATE) Shift Tab now exits from XTREE with EXITCODE -35 (if the VK_TAB bit is set in the FLAGS parameter).
923.1.1
Fix compiler bug with expansion of multiple defined symbols on one line.
923.1.2
(WINDOWS/ATE) Deal with problem of embedded quotes in INFLD fields and also in AUI_CONTROL text strings. These strings are now "escaped" by replacing literal quotes with %22 (22 is the representation for the ASCII quote character). If you wish to manually output such a string using TAB(-10,20), you must replace the quotes with %22 sequences yourself. (Yet another reason to let XCALL AUI,AUI_CONTROL do the work for you.)
923.1.3
Fix INFLD bug with not beeping when rejecting characters.
923.0.1
COMPIL/X:1 (and above) now supports hex, octal, and ASCII radix notation for numeric literal values, i.e.:
&h100 ! hex 100 (256 decimal)
&o100 ! octal 100 (64 decimal)
'A' ! ascii A (65 decimal)
These can be used in expressions where you would otherwise be able to use numeric literal values.
923.0.2
COMPIL/X:1 (and above) now supports the DEFINE statement for defining constants, for example:
DEFINE TCRT'REVON = 32
DEFINE XTF'CTRLC = &h01000000
DEFINE MY'NAME$ = "JACK"
The names following the DEFINE must conform to the normal rules for variable names (start with an alphabetic character and contain alphabetic, numeric and "'" characters plus an optional $ or % suffix).
The definition must either be a literal numeric value (as in the first two examples above), or a quoted string value.
These definitions act like macros, substituting the definition into the source code before each line of the program is compiled. Because of this, compiler error messages will usually display the line after macro expansions (which may look strange at first, but since the error messages also show the line number, it allows you to compare your source code to the result after the macro replacements.)
From a logic standpoint, the result is equivalent to using MAP statements, i.e.:
MAP1 TCRT'REVON,B,1,32
MAP1 XTF'CTRLC,B,4,&h01000000
MAP1 MY'NAME$,S,4,"JACK"
The main advantages of DEFINE over MAP statements are:
| • | You cannot assign a value to a DEFINEd symbol; thus, they act like true constants. |
| • | DEFINEd constants take up no space in the RUN file unless they are used. Thus it now becomes practical to create ++include files which define constants for virtually every situation, without worrying about the overhead. (They do create some compiler overhead, but is that really something we need to worry about?) |
| • | Even for constants that are referenced in the program, constants generally save space in the RUN file. A non-subscripted MAP statement with an initial value takes 16 bytes, and then it takes another 2 or 3 bytes to reference it in the code. A constant takes zero bytes to define, and generally only 2 bytes to reference. (Depending on the number of significant binary digits in the constant, it may take 4 or 6 bytes to represent. But in the vast majority of cases, DEFINEd constants are small integers or powers of 2 and can be represented in only 2 bytes. Strings require 2 bytes plus their length to reference as constants, so in that case, the use of constants may actually increase the size of the RUN, assuming they are referenced multiple times.) |
| • | Because of the above, converting MAP statements to DEFINEd constants (assuming they are never assigned more than one value) will result in smaller RUN files, with a very slight bonus in performance, at the cost of a slight increase in compile times. But the main advantage comes in programming clarity when you use meaningful symbolic names for constant values in place of literal number or mapped variables. |
Including a file containing an unknown set of DEFINEs is generally safe and should have no side effect on an existing program (unless you deliberately use the defined constants). Some scenarios to be aware of though:
| • | If a DEFINE precedes a MAP statement for the same identifier, the MAP statement will generate a syntax error, because the MAP statement identifier will be replaced by the value of the DEFINEd symbol before it gets compiled. For example: |
DEFINE CTLOP'ADD = 1
MAP1 CTLOP'ADD,B,2,1
Since the CTLOP'ADD in the MAP statement will be replaced by 1, it will be compiled (and a syntax error generated) as if it were:
MAP1 1,B,2,1
| • | If a DEFINE conflicts with an unmapped variable, a similar thing will happen when you try to assign a value to the variable: |
DEFINE CANADA'VAT = .15
CANADA'VAT = .16 ! assignment to unmapped variable
This will also cause a syntax error, because it will look to the compiler as if it were:
.15 = .16
(If the unmapped variable is never referenced, you won't get a syntax error, but then again it won't matter to your program operation either.)
| • | The one case where you might have a problem is if you reference an unmapped (and unassigned) variable in an IF statement, i.e.: |
IF CANADA'VAT = .16 THEN ...
This will compile as if it were:
IF .15 = .16 THEN ...
That is a perfectly legal statement, and won't be what you expected (although your test of an unmapped/unassigned variable probably won't be what you wanted either, unless you were counting on it being zero). To eliminate this possibility, compile your programs with /M !!!
| • | If you attempt to DEFINE a symbol that has already been MAPPED, you will get a duplicate label error. So it doesn't really matter whether you DEFINE all your symbols first or do all your MAPs first, or mix them together; any conflict between the two will generate a compilation error. |
923.0.3
COMPIL/X:2 and above now supports nesting of ++INCLUDE files up to three levels deep. (The limit is arbitrary, but was chosen based on the belief that beyond three levels, things are probably just going to get too confusing to be practical.)
As a visual aid to helping you keep track of the nesting level of lines with errors, they now include "+", "++", or "+++" in front of the line number, depending on the nesting level. (Previously, the line number was always preceded by "++" for includes.) Also, the "Copying from" message is now indented to show the nesting.
When an ERSATZ specification is used with ++INCLUDE, it becomes the default for any ++INCLUDEs nested below it. So for example, if the main program contains ++INCLUDE ASHINC:ASHELL.BSI and ASHELL.BSI contains ++INCLUDE ASHELL.DEF, then the default location for ASHELL.DEF will be in ASHINC:. If not found there, or if the ++INCLUDE includes an explicit ersatz or dev:[p,pn] specification, the normal rules apply. (This feature allows you to split an existing .BSI into a .BSI and a .DEF, without having to hardcode the location of the .DEF)
923.0.4
COMPIL/X:2 and above now supports the use of the underline character in variable and constant names. The recommended use for underlines would be to use them in constants to distinguish them from variables. If you adopted this recommendation, then you would be able to instantly recognize that MBF_STATIC was a constant and not a variable.
923.0.5
As a first step towards taking advantage of the above compiler features, we have split out the symbolic constants from some of the common include files we release (e.g. ASHELL.BSI and XTREE.MAP) and defined two sets of them: one using apostrophes for compatibility with existing source code, and one using underlines for moving forward. We are also moving towards using the file extension DEF for include files which only contain definitions (no MAP statements or code).
For example, in the case of ASHELL.BSI, all of the MAP statements that previously were used to define constants (e.g. MBF'KBD, GOP'STRICT, etc.) have been moved to ASHELL.DEF and ASHELLO.DEF. (ASHELL.DEF contains versions using the underline notation, i.e. MBF_KBD, and ASHOLD.DEF contains versions using the apostrophe notation, i.e. MBF'KBD.) Both are ++INCLUDEd in ASHELL.BSI. (ASHELL.BSI also contains some executable code, so it was somewhat wasteful to include it just for the sake of getting the symbolic constants. But for programs that do ++INCLUDE ASHELL.BSI, the nested include feature will define all of constants using both the ' and _ notation. For new development, you would be encouraged to just ++INCLUDE ASHELL.DEF.
In the case of XTREE.MAP, and the symbols for any other A-Shell routine which is embedded with A-Shell, we have moved the symbols to ASHELL.DEF and ASHELLO.DEF. (There seems little point in having separate DEF files for XTREE, MSBOXX, INMEMO, etc. since they are all routines that are embedded within A-Shell.)
923.0.6
(Windows/ATE) Fix problem with deleting nested dialogs in non-FIFO order. This was happening if you used a clear screen to clear all controls and there were multiple dialogs on the screen. Problem was causing Invalid Window Handle errors when creating subsequent controls.
923.0.7
(ATE) A new checkbox option has been added to the Login Parameters dialog: "Use Password for FTP Only". When checked, the password is not sent during the initial login, forcing the user to actually type the password. However, for program-initiated FTP transfers, the password will be used. The theory here is that you might not want to allow anyone to log in to the server just by clicking on an ATE profile with an embedded password. But, once they are logged in, you don't want to have to ask the again for their password in order for the application to initiate file transfers. The user cannot initiate file transfers themselves in the pure ATE environment, and if you use the Madics interactive FTP option, it will now also force a manual login if this checkbox option is set. So the FTP option with automatic password shouldn't introduce any security loophole. (Note: the password is encrypted in the registry, and clearing the checkbox also clears the password, so there is no opportunity for the user to bypass the security by sitting down at another user's PC and trying to adjust the connection profile.)
923.0.8
(WINDOWS/ATE) In addition to the above mentioned symbols, the following new symbols have been added to ashell.def:
! *** AUI classes ***
define AUI_CONTROL = "CONTROL" ! [112] control ops
define AUI_WINDOW = "WINDOW" ! [112] window ops
define AUI_ENVIRONMENT = "ENVIRONMENT" ! [112] get environment info
define AUI_EVENTWAIT = "EVENTWAIT" ! [112] wait for events
define AUI_MENU = "MENU" ! [112] menu ops
define AUI_IMAGE = "IMAGE" ! [112] image display
define AUI_HTMLHELP = "HTMLHELP" ! [112] HTML-style help ops
As a notational shorthand, we will now start referring to the above routines by the symbol names, i.e. AUI_CONTROL (as opposed to the more awkward AUI,"CONTROL", or the ambiguous "CONTROL".)
! *** [112] AUI_CONTROL opcodes
define CTLOP_INFO = 0 ! [112] query a control
define CTLOP_ADD = 1 ! [112] add a control
define CTLOP_CHG = 2 ! [112] change a control
define CTLOP_DEL = 3 ! [112] delete a control
define CTLOP_CLR = 4 ! [112] clear controls in area
define CTLOP_QRYCB = 5 ! [112] query checkbox
define CTLOP_SVA = 6 ! [112] save controls within area
define CTLOP_RSA = 7 ! [112] restore saved controls
define CTLOP_SBCH = 8 ! [112] start batch
define CTLOP_EBCH = 9 ! [112] end batch
define CTLOP_GETID = 10 ! [112] get control ID (by coords)
define CTLOP_PANE = 11 ! [112] set TAB control pane
! *** Symbolic names for dummy AUI_CONTROL parameters...
define NUL_CTLID = 0
define NUL_CTEXT$ = ""
define NUL_CSTATE = 0
define NUL_CTYPE = 0
define NUL_CMD$ = ""
define NUL_FUNC$ = ""
define NUL_CSTATUS = ""
define NUL_SROW = 0
define NUL_SCOL = 0
define NUL_EROW = 0
define NUL_ECOL = 0
define NUL_FGC = -2
define NUL_BGC = -2
define NUL_FONTATTR = 0
define NUL_FONTSCALE= 0
define NUL_FONTFACE$= ""
define NUL_TOOLTIP = ""
define NUL_PARENTID = 0
define NUL_WINCLASS$= ""
define NUL_WINSTYLE = 0
define NUL_WINSTYLEX= 0
The above symbols are useful when the form of the AUI_CONTROL call requires some arguments to be specified only as placeholders so you can specify later ones. For example, when querying checkboxes, instead of:
xcall AUI,"CONTROL",5,CID(I),"",0,0,"",CB(I),STATUS
you can instead use the more clear:
xcall AUI,AUI_CONTROL, CTLOP_QRYCB, CID(I), NUL_CTEXT$, &
NUL_CSTATE, NUL_CTYPE, NUL_CMD$, CB(I), STATUS
Admittedly it is longer, but much more clear and much less likely that you will confuse yourself or the next person to look at your code.
!*** Symbolic names for XTREE XTR'OPCODES
define XTROP_CREATE = 0 ! add
define XTROP_REPLACE = 1 ! replace data
define XTROP_APPEND = 2 ! append to existing data
define XTROP_DELETE = 3 ! delete xtree
define XTROP_RESELECT = 4 ! reselect (existing ctl, data)
define XTROP_DELSEL = 5 ! delete selected rows, then resel
923.0.9
(WINDOWS/ATE) New EVENTWAIT options, behavior:
! *** [108] AUI,EVENTWAIT opcode flags
define EVW_NEXT = &h00000001 ! start with focus on control AFTER s
define EVW_NOWAIT = &h00000002 ! set focus and exit without waiting
define EVW_NOWRAP = &h00000004 ! exit when hitting edge of group (in
define EVW_NOFOCUS = &h00000008 ! no changes to focus (just wait for
define EVW_NUMERIC = &h00000010 ! allow numeric keyboard input (16)
define EVW_DESCEND = &h00000020 ! descend into subgroups of parent (3
define EVW_SIBLINGS = &h00000040 ! expand range to include siblings of
define EVW_INFLD = &h00000080 ! [113] support INFLD
define EVW_PREV = &h00000100 ! [113] opposite of EVW_NEXT
define EVW_SQUELCH = &h00000200 ! [113] squelch radiobtn exits on arr
define EVW_TABEXIT = &h00000400 ! [113] exitcode 7/13 on TAB/ShiftTAB
The TSTEVW program in the EXLIB has been updated to illustrate these.
923.0.10
(WINDOWS/ATE) New INFLD TYPE ||] prevents field width from being expanded by various well-meaning logic within INFLD. For example, combo boxes smaller than 6 characters wide typically get an extra 3 characters worth of width to account for the space taken up by the drop-down button. And date fields get one to four extra columns worth to handle the optional checkbox, drop-down button, slashes, etc. Generally these automatic additions are a good thing, preventing the field data from being squeezed unnecessarily. But if your screen space is tight or you have some other reason to want to be precise, just add ||] to your TYPE codes.
923.0.11
(WINDOWS/ATE) Back out the change to the positioning of groupboxes which was implemented in 922.3. That feature is still available, but now requires the addition of MBF'ALTPOS to the MBF'GROUPBOX flag when creating the groupbox. (This preserves backwards compatibility for programs that "liked" the old layout.)
923.0.12
(WINDOWS/ATE) When clicking on an inactive XTREE, the row clicked on is now automatically passed to the XTREE control so that it can select that row, rather than the first row. For single-selection XTREEs, in order for this to work, you must set ANSWER=0. (Otherwise, the specified ANSWER will override the clicked row to determine the new selection.) For multi-selection XTREEs, the clicked on row will be added to the existing selections.
The XTRA4 program in the EXLIB program illustrates this.
923.0.13
(WINDOWS/ATE) In order to expand the support for right click actions, you may now add an "r" to a virtual key symbolic code in order to declare that right click is enabled. For example:
%VK_xF201%
The above symbolic sequence will send virtual extended function code 201, which results in EXITCODE -201. Right click will be ignored. But if you insert an "r" between the "x" and "F", as follows:
%VK_xrF201%
then both left and right click will be supported. If right click, the returned EXITCODE will be +201 (instead of -201). This is currently only designed to work with buttons and XTREE controls, but may be expanded to others. Note that you should only use this technique with F numbers higher than 50, since below that, a right click might be confused with some other internal INFLD exitcode.
Also, it is no longer necessary to include the leading and trailing % symbols with the above notation. That is, you can save space by just specifying your keyboard click string as "VK_xrF201" instead of "%VK_xrF201%". (The chance of anyone wanting to output a literal string starting with VK_ has been considered not worth the extra typing of the % signs.) Also, the shortening of these strings by two characters is critical for including them in the XTR'KBDSTR field in XTREE, which unwisely only allowed for 10 characters.
The XTRA4 program in the EXLIB illustrates this: try right-clicking on the xtree controls (when inactive) or the Copy and Delete buttons.
923.0.14.
(WINDOWS/ATE) A new XTREE column flag (for use with advanced syntax) "X" may be added to "T" (editable checkbox) or "E" (editable text) fields to cause XTREE to exit with the field is edited. The EXITCODE in this case will be -48. The application can determine the cell being edited from the new XTR'XROW and XTR'XCOL fields:
MAP1 XTRCTL ! extended XTREE parameters
MAP2 XTR'OPCODE,B,1 ! 0=normal (create), 1=replace data,
! 2=append, 3=delete, 4=select,
! 5=delete one row
MAP2 XTR'CTLNO,B,1 ! 0=1st pcklst ctl, 1=2nd, 2=3rd
MAP2 XTR'ITEMLINES,B,1 ! max # dsp lines of text per item
MAP2 XTR'TREELINESTYLE,B,1 ! 0=none,1=solid,2=dotted
MAP2 XTR'SHOWBUTTONS0,B,1 ! Show level 0 tree btns (0=no, 1=yes)
MAP2 XTR'SHOWBUTTONS,B,1 ! Show level 1+ tree btns
MAP2 XTR'SHOWGRID,B,1 ! Show grid lines (0=no,1=yes)
MAP2 XTR'GRIDSTYLE,B,1 ! 0=vert, 1=horz, 2=both
! (0-2 = solid, 3-5 = dotted)
MAP2 XTR'TRUNCATED,B,1 ! Show truncation indicator
MAP2 XTR'SELECTAREA,B,1 ! Set to 1
MAP2 XTR'FLYBY,B,1 ! Fly by highlighting (0=no, 1=yes)
MAP2 XTR'SCROLLTIPS,B,1 ! Show scroll tips (0=no, 1=yes)
MAP2 XTR'COLUMNACTIVE,B,1 ! Active column (on entrance & exit)
MAP2 XTR'COLUMNSORT(3),B,1 ! Columns sorted by (1=1st col)
MAP2 XTR'SORTORDER(3),B,1 ! Sort order
! 0=none,1=ascending,2=descending
MAP2 XTR'KBDSTR,S,10 ! kbd click string
MAP2 XTR'USETHEMES,B,1 ! 1=use XP themes (if available)
MAP2 XTR'PARENTID,B,2 ! ID of parent control (e.g. TAB)
MAP2 XTR'SHOW3D,B,1 ! 1=use 3D style [105]
MAP2 XTR'HIDEHEADER,B,1 ! 1=hide header [106]
MAP2 XTR'XNAVCOD,B,1 ! [109] cell editing navigation code
MAP2 XTR'XNAVMASK,B,1 ! [109] internal use
MAP2 XTR'XROW,B,4 ! [108] current editing row
MAP2 XTR'XCOL,B,1 ! [108] current editing col
MAP2 XTR'UNUSED,X,19 ! unused [106] was 27 [109] was 26
The XTR'XNAVCOD and XTR'XNAVMASK fields are used to pass information about how the field was exited, so that when you re-enter, it can automatically select the next appropriate editable cell. If you want to reject the value which was entered (i.e. force it to be edited again) then set XTR'XNAVCOD = 0.
The manner of passing the editable text data back and forth between XTREE and the application has changed slightly. Previously, the data was passed to XTREE via the main array, and on exit the data was passed back via the ANSWER array. While this is still true, if XTR'OPCODE is not zero, the contents of any editable text fields in the ANSWER array will override the corresponding value in the main array. For example, consider a 5 column list in which the 2nd column is editable text. When initially setting up the XTREE, you can load up the ANSWER array with spaces and put all of the data, editable or not, in the main array. When the user edits one of the cells in the 2nd column, if the column was defined with "EX", then XTREE will exit, returning the entire editable column, including the field just edited, in the ANSWER array. The application can locate this field by the XTR'XROW parameter. If the data is valid, then the application can just re-enter the XTREE, with XTR'OPCODE = 4. If, on the other hand, the data input was invalid, the application can compare it to the data in the main array, and reset the field in the ANSWER array back to match the main array, and set XTR'XNAVCOD = 0. Then, when it returns to XTREE, the edit focus will return to the field in question, with the original data.
The XTRA5 sample program illustrates the use of editable cells and validation.
923.0.15
(WINDOWS/ATE) A simple form of modeless dialog is now supported. (A modeless dialog does not suspend the operation of the main program until the dialog is closed.) To create, use MBF_DIALOG+MBF_MODELESS. The ending row and column of a modeless dialog may be beyond the limits of the screen or window. These dialogs are mainly useful for displaying information that is not critical to the main window, allowing the user to push it out of the way if desired.
See the TSTSCR, XTRA4, and XTRA5 sample programs in the latest EXLIB for examples of using modeless dialogs to display scrolling status messages regarding the program operation.
SCRSTS.SBX 1.1(103) supports an option to create the modeless dialog automatically (which is well used in the above sample programs.)
