933.1.1
(Windows/ATE) Fix problem with TAB(-1,0) not actually deleting controls. It cleared them, but they weren't really gone and would come back at inopportune times.
933.0.1
(Windows/ATE) New field added to XTREE XTRCTL parameter: SKEY,S,10 If non-null, and the current XTREE is in single-select mode, and the XTR'COLUMNACTIVE parameter is not zero, then the initial selection is established by searching the active column for the specified string (overriding the ANSWER parameter, which normally sets the initial selection.)
XTREE.MAP edit [112] has been updated to map the new field, which was added to the end (reducing the FILL size by 10). The last several fields of XTRCTL are now:
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 row
MAP2 XTR'XCOL,B,1 ! [108] current col
MAP2 XTR'EXPANDLEVEL,B,1 ! [110] 1=all level 0, 2=all levels
MAP2 XTR'SKEY,S,10 ! [112] search key
MAP2 XTR'UNUSED,X,8 ! unused [112] was 18
The latest XTREE.MAP is available in [907,16] of the SOSLIB release 111.
The XTRA3 sample program (in [908,21] of the EXLIB) has been updated to allow you to set the SKEY field.
Notes
| • | SKEY does not require a trailing null |
| • | A match will succeed as long as the contents of SKEY matches the start of the data in the column (i.e. "Ab" will match "Abbey Road"). |
| • | SKEY is not cleared or set by XTREE |
933.0.2
(Windows/ATE) XTREE column sort for dates now supports the SBR=CCYY:## parameter in the MIAME.INI for determining the century if only YY is specified. The default value is equivalent to SBR=CCYY:60, meaning that any YY value of 60 or higher is assumed to 19YY; otherwise it is assumed to be 20YY.
The XTRA3 sample program has been updated to show a mixture of YY and CCYY values to confirm the new sorting logic.
933.0.3
(Windows/ATE) A-Shell command line switch -zt is similar to -z (hide window) except that the task appears in the Alt-TAB list.
933.0.4
(Windows/ATE) Millirows system has been altered so that the EROW and SROW coordinates are more logically consistent with each other. (WARNING: this will affect existing programs using millirows!!!) In the new system, in order for a control to occupy a single "row", its EROW coordinate should be 1000 millirows higher than the SROW coordinate. (In the old system, millirows were like standard rows in that SROW=EROW was interpreted to mean that the object was one row high.) Some examples will make this clear:
Coordinates |
Result |
|---|---|
SROW=2: EROW=2 |
Control is one row high. |
SROW=2000: EROW=3000 |
This is equivalent to the previous example. Note that when converting EROW from standard rows to millirows, add 1 and then multiply by 1000. When converting SROW, just multiply by 1000. |
SROW=2100: EROW=3100 |
This is equivalent to the previous example, except that it is shifted down by 1/10 of a row (100 millirows). |
SROW=2400: EROW=2400 |
This control is only 1 millirow high, which only makes sense except in the case of rectangles, i.e. (SZCLASS="STATIC", DWSTYLE=SS_BLACKRECT or SS_GRAYRECT or SS_WHITERECT). |
This new system makes millirows more logically analogous to pixel coordinates, except for the fact that the external leading is still subtracted from the bottom coordinate of the control. For example, consider two controls in adjacent rows. The first is specified as SROW=3000: EROW=4000 and the second is SROW=4000: EROW = 5000. Do the two controls touch? Normally, no. This is because we subtract the external leading from the resulting bottom coordinate. So if the external leading was 6, the two controls would still be separated vertically by 6 pixels, even though the bottom coordinate of the top control matches the top coordinate of the bottom control. This is a bit strange perhaps, but is very handy if you purpose in using millirows is simply to shift an object up or down by a small amount.
To cancel the automatic adjustment of the bottom coordinate to account for the external leading, specify the MBF_ALTPOS flag in the CTYPE parameter. When used in conjunction with an EROW specified in millirows, the usual interpretation (i.e., causing an "aesthetic adjustment" to the size or position of certain control types) is changed to simply disable the automatic subtracting of the leading from the bottom coordinate.
The 1.0(103) update of the GUILIN sample program in the EXLIB illustrates this the difference by drawing a pair of columns made up of lines 1000 millirows high (in the lower right corner of the screen). The first column has gaps between the lines due to the leading; the second column uses MBF_ALTPOS to eliminate them. Note that we could also have eliminated them by just adding more to the EROW coordinate; this is less convenient though since we don't have a good way of knowing the leading or converting it from pixels to millirows. (Overlapping wouldn't matter for lines but it might for some other controls.)
Notes on Millirows
| • | Millirow 1000 is the top of the usable area of a dialog. It might have been more logical for millirow 0 to have been the top, but this offset does provide some advantages. One is that it seems more consistent with the fact that the first row in standard coordinates is 1, not 0. This makes it somewhat easier to mentally convert from ROW x to the equivalent millirow (1000x), and dovetails nicely with the fact that static text is currently aligned at the top of the control area. Consequently, if you want to shift a text label up by 1/4 row, just multiply the SROW by 1000 and subtract 250. Another advantage is that it eliminates the ambiguity that would otherwise arise if trying to position a control within 200 millirows of the top of a dialog. (If you needed to use a millirow value of between 1 and 200 to do that, it would intepreted as a standard row.) |
| • | In the main window (i.e. not a dialog), there will be left, top, right and bottom margins which are made up of the pixels left over after determining the largest integer grid size that will accommodate the rows and columns required. Thus, millirow 1000, just like row 1, will not necessarily be the very top of the window. You can specify a millirow value of between 200 and 1000 to shift the control up into that margin space, although it may get clipped if your adjustment is more than the margin. |
933.0.5
(Windows/ATE) XTREE wasn't returning XTR'XROW and XTR'XCOL values for editable checkboxes with validation if you clicked on them. (It was only returning the information if you navigated to them by keyboard.)
Also, it now returns XTR'XROW set to the selected row if you exit from an XTREE containing editable cells by some means other than validating an editable cell. You can distinguish between the cases by the value of EXITCODE. (If EXITCODE=-48, then it exited to validate a cell; if EXITCODE=0, then it exited because user selected a row.)
Also, fix a problem in which the XTR'XROW returned during editable cell validation was correct after using horizontal navigation keys to wrap from one row to another.
933.0.6
(Windows/ATE) INFLD wasn't redisplaying a combobox control correctly after removing characters with the Rubout (aka "Backspace") key.
