928.0.1
(Windows/ATE) A new, more adaptable, coordinate system is now available for use with dialogs, by adding the MBF_ALTPOS flag when creating the dialog. In this case, the meaning of the row/col coordinates is adjusted. Normally, these units are based on the row/col grid of the main window. So, for example, if the main window is 800 x 520 and is currently configured as 80 columns by 26 rows (24 + 2 status lines), then the grid size is 10 pixels by 20 pixels, and a dialog starting at row 5 col 7 would start 5x20=100 pixels down and 7x10=70 pixels over from the upper left corner of the main window, give or adjustments for the size of the menu and title bars and borders.
The main problem with the above system is that it is directly proportional to the size of the main window. Sometimes that is just what you want, but a more typical "Windows" approach to dialogs is to design them for a certain "logical" size , and then expect them to appear approximately in that size regardless of the physical size of the main parent window.
The MBF_ALTPOS flag gives you this "constant logical size" effect by basing the dialog 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. When MBF_ALTPOS is specified when creating a dialog, the grid size is computed to be 120% of the height of the standard combobox, and 120% of the "average" character width for the current GUI font. This grid automatically adjusts itself based on the current GUI font, screen resolution, DPI, etc. and thus gives you a dialog which is "logically" the same size on all desktops. As with "standard Windows dialogs", the only problem you need to worry about when designing them is that you 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 can't 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 reduce 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 5 and end at row 15, you get 11 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 TSTEVW sample program has been upgraded to deal with this by subtracting one from the height of the dialogs if you select the MBF_ALTPOS option.
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 can't start up or to the left of the previous dialog.) But since dialogs can be dragged around the screen by the user, it probably won't 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 it's 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.
928.0.2
(IMAGING) The image library (VIC32.DLL) is now somewhat more tolerant of an apparently common problem in JPG files in which the file size does not match the internal file header. Most programs seem to display these files without complaint, whereas some will warn of potentially bad data. Previously the IMAGE subroutine would return error -62 and refuse to display the image.
928.0.3
(WINDOWS/ATE) Multi-line buttons are now highlighted more appropriately by the EVENTWAIT routine when they get the focus. (Previously they were switching back to single-line mode when they had the focus, which didn't look very good.)
928.0.4
Fix bug in XTREE "c" column type (introduced in edit 927). It wasn't always looking at the right column to pick up the color value.
Fix bug in XTREE DspWid column setting, where it was sometimes being ignored, particularly in file mode. This was actually making it appear as if the merge column types ("O" and "o") were not working, since the first column width was being set to the maximum to contain all the data so that merge was not needed.
928.0.5
(WINDOWS/ATE) ASHICO.DLL 1.0.0.3 adds 5 new icons: lightbulb_on, lightbulb_off, text, text_find, and text_tree. See updated ICODLG sample program in EXLIB.
928.0.6
(WINDOWS XP) A problem in which A-Shell would "disappear" immediately upon launching under versions of XP without the service packs installed has been worked around. It is still highly recommended that you install Service Pack 2, but not absolutely required for A-Shell.
928.0.7
(WINDOWS/ATE) It is now possible to show a dialog without showing the main window, using one of the following techniques:
| • | You can launch a new session of A-Shell with the -z or -zi switch (both of which make the main window invisible) and use a startup command that launches a program which shows a dialog. Note however, that the dialog should be created with MBF_ALTPOS flag or else it will likely be sized inappropriately. |
| • | You can hide the main window on demand using the XCALL AUI,AUI_WINDOW,0 and then proceed to create a dialog as noted in 7A above. |
928.0.8
(Windows/ATE) Save and restore screen operations now handle graphic control lines just like other controls. (Previously they were being ignored by the save/restore.)
928.0.9
(XTREE) New field added to XTRCTL (XTR'EXPANDALL) to control whether a multi-level list is displayed initially in collapsed or expanded form. By default (0), the list is collapsed, unless an item is selected, in which case that branch is expanded so that the item is visible. When you set XTR'EXPANDALL to 1 or above, all items are expanded. (At some point, we may be able to offer a choice between expanding just the level 0 items and expanding all the items, in which case 1 would be used to expand just the level 0 items; for now any value above 0 expands all items.)
XTREE.MAP edit [110] has been updated to map the new field, which was added to the end (reducing the FILL size by 1). 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'EXPANDALL,B,1 ! [110] 1=all level 0, 2=all levels
MAP2 XTR'UNUSED,X,18 ! unused [110] was 19
The latest XTREE.MAP is available in [907,16] of the SOSLIB release 108.
