Please enable JavaScript to view this site.

A-Shell Reference

When the start row or end row coordinate of a control (created by AUI_CONTROL, AG_CONTROL, INFLD, etc.) is greater than 200, it is assumed to be in units of "millirows" (1000 to the row) rather than rows. This allows the vertical position and size of a control to be more finely adjusted than is possible with integer rows or even with the MBF_ALTPOS option.  

In general you will get the same results whether you specify an srow value in units of rows or multiply it by 1000. There are some exceptions, though, where the default position of a row is adjusted up or down based on some internal logic, and in such cases, switching to millirows may defeat the internal logic, causing the line position to change more than expected. For example, with single row horizontal line controls, the default position is in the middle of a row. If you switch from, say, row 5 to millirow 5000, the second line will be half a row higher than the first. In general though, if you want to move a control up or down by a slight amount, multiply the srow value by 1000 and then offset it by some fraction of 1000. To convert erow to millirows, first add 1 and then multiply by 1000 (e.g. erow 5 is equivalent to millirow 6000).

In order for a control to occupy a single "row", its erow coordinate should be 1000 millirows higher than the srow coordinate. 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 in the case of lines, i.e. (SZCLASS="STATIC", DWSTYLE=SS_BLACKRECT or SS_GRAYRECT or SS_WHITERECT).

 

The system used here makes millirows 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 your 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 sample program GUILIN in EXLIB:[908,24] illustrates this 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 would have had to query the current leading value (see MX_WINSETTINGS) and then converted from pixels to millirows (see AUI_WINDOW). (Overlapping would not matter for lines but it might for some other controls.)

Notes

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 have been otherwise interpreted 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 into which the main window is divided (via Tab(-5,rows) or Tab(-6,cols)). 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.