The standard A-Shell coordinate system is based on dividing the main window size by the currently defined number of rows and columns. To put it another way, the basic unit of the coordinate grid is the text-based coordinate cell size. This fact helps facilitate the coexistence of text and GUI elements on the same window, but it has two shortcomings for GUI development:

•   The grid size is dependent on the actual size of the main A-Shell window, which can be easily adjusted, thus leading to a grid size that may be vastly too big or too small for a particular screen environment

•   It is based on fixed-pitch fonts which have little to do with the proportional fonts used in GUI environments.

The problems become particularly noticeable with dialogs, which are typically designed to be a certain size relative to the information contained within, and not dependent on the size of the window that called the dialog. Yet, with the normal A-Shell grid system, the dialog, being just another control, uses the same grid as the parent window, making the dialog layout helplessly dependent on the user setting the main window to a reasonable size.

To overcome these shortcomings, the MBF_ALTPOS option may be specified when a dialog is created in order to have the dialog use a more flexible coordinate system which is independent of the A-Shell main window and which self-adjusts to provide a "constant logical size." This is accomplished by basing the alternate grid on the current standard GUI font size. In addition to being independent of the size of the main window, it also adjusts to the "DPI" of the Windows desktop.

The units of the alternate grid are still based on individual characters, which allows you to lay out the dialog almost as if it was a traditional text screen (where one character equals one column). Only here, we are using an "average character width." So while you can count the actual number of characters in your dialog labels to determine the sizes needed for the controls, as with "standard Windows dialogs", you need to allow enough room for the variability in character widths of variable text, since capital letters are on average twice as wide as lower case in the typical GUI font. So you cannot count on a 20 character string fitting in 20 "columns" of the dialog. But if you use mostly lower case, it should be a rough approximation, and if you allow a little extra space, your dialogs should be pretty resilient to local environment settings.

As an added bonus, this coordinate system is reasonably compatible with the old one, meaning that adding MBF_ALTPOS to an existing dialog will probably not break it, and may improve it.

There is one significant difference that must be noted when using the MBF_ALTPOS option, involving the way the height of the dialog is calculated. In the original dialog implementation, the total dialog height was based on multiplying the row height of the main window by the number of requested rows in the dialog coordinates. But this calculation included the dialog border and title bar, which reduced the usable number of rows of the dialog. A margin was added to the bottom, but the net effect is that normal dialogs have one less usable row than they ought to. And when the dialog gets too small, even that last row may be truncated. Arguably this should be fixed since it is confusing, but doing so now would probably affect too many programs.

However, when the MBF_ALTPOS flag is specified, the dialog height is calculated to take into account the border and title bar, so that you always get the full number of rows specified. For example, if a dialog was coded to start at row five and end at row fifteen, you get eleven usable rows.(In addition, there is a half-row margin at the bottom, which gives buttons placed on the bottom row of a dialog a little breathing room.)

TRMCHR.SBR is aware of this distinction, and returns the full number of rows in WINROWS when the MBF_ALTPOS flag was used to create the dialog. Otherwise, it returns one row less, which generally works but is still an approximation since the amount of space lost due to the border and title bar could amount to more than one row if the rows are short enough.

This "correction" to the height calculation of dialogs may cause your existing dialogs to appear to have an extra row at the bottom (or, if you used the BTNMNU. SBX option to put buttons on the bottom row, then the extra space will appear above that.) The sample program TSTEVW in EXLIB:[908,20] has been upgraded to deal with this by subtracting one from the height of the dialogs if you select the MBF_ALTPOS option. Another way to deal with the "correction" is to check the option on the Dialog Sizing dialog labeled "Included caption in dialog height." This, however, only applies to dialogs that were forced to use the alternate grid system (aka Windows desktop font size grid) by means of the radio button choice in the Dialog Sizing dialog. (The combination of the two options allow you to experiment with switching to the alternate grid without actually modifying any code. Once you decide you like it, you can explicitly add the MBF_ALTPOS option to your dialog settings in your code, and adjust the dialog height at the same time.)

Another minor difference when using the MBF_ALTPOS option, is that the starting row/col coordinates of the dialog are interpreted as relative to the main window, and not to the parent dialog. This only matters for nested dialogs, and allows you more flexibility in positioning such nested dialogs (which otherwise cannot start up or to the left of the previous dialog.) But since dialogs can be dragged around the screen by the user, it probably will not have any significant deleterious effect on existing dialogs that are converted to the new grid system.

Note that a nested dialog will automatically inherit the ALTPOS grid size from its parent dialog (if the parent dialog had the ALTPOS option). But it will not automatically inherit the alternate positioning logic or height calculation. That is, if the parent dialog uses MBF_ALTPOS, then any nested child dialog will automatically use the same spacing. But unless the child dialog also uses MBF_ALTPOS, its upper left corner will be positioned relative to its parent, and its bottom row usability will be related to the relationship between the row height and title bar height. Otherwise, if the child dialog does use MBF_ALTPOS, then its upper left corner will be relative to the main window and use the same height logic, and thus if it has the same coordinates as the parent dialog, it will exactly overlay it.

One additional advantage of the Alternate Dialog grid is that it allows you to create maximized dialogs, either under program (MBST_MAXIMIZE) or user control (MBF_MAXBUTTON). When such a dialog is maximized (or normalized), all of the controls scale accordingly. If the size difference between the normal and maximized state is more than 10% in each direction, the fonts will be scaled as well, as will the column sizes of any XTREE columns which have Dspmin or Dspwid Advanced Coldef Options. The fonts within XTREE controls, however, will not be resized.