The GUI enhancements described here for edit 863 are not really even worthy of the term "beta", and are likely to be further modified before released. They are only offered here for those intrepid developers who want to participate in the design process.
863.1
(Windows) - Proportional font text strings can now be displayed using static text controls. These can be added / modified / deleted similarly to buttons using the same MIAMEX,119 call:
xcall MIAMEX,119,OPCODE,BTNID,BTNTXT,STATE,TYPE,CMD,FUNC,STATUS, SROW,SCOL,EROW,ECOL{,FGC{,BGC}}
All parameters are the same as for buttons, except for the following new TYPE flags:
ASHELL.BSI symbol |
Value |
Meaning |
|---|---|---|
MBF'SUNKEN |
4096 |
Control given a "sunken" look |
MBF'STATIC |
262144 |
Create static text control |
MBF'WORDELLIPSIS |
2097152 |
If text doesn't fit, end with ... |
MBF'PATHELLIPSIS |
4194304 |
For paths, if too long, insert /.../ |
MBF'DIM |
8388608 |
Dim attribute |
MBF'FRAME |
33554432 |
Draw a frame border (around static) |
The optional FGC and BGC parameters may be used to specify something other than the system default colors. FGC (foreground color) may be set to any of the standard color numbers 0-15, or -1 for the current foreground color, or -2 for the Windows standard "button text" color (usually black, but subject to change with the desktop schemes).
BGC (background color) currently uses a different color scale (since "normal" Windows programs are not likely to paint text using arbitrary background colors. The default (used if set to -1) will be the system "button face" (usually gray) color. When using these Windows controls, it is highly recommended that you use MIAMEX,91 to associate your screen background color with the "system background" (aka "button face") color, in which case text displayed using the default BGC will appear "normal". Any other value for BGC is interpreted as specifying one of the system colors, which are defined in the latest ashell.bsi with symbols named COLOR'xxxx. The most likely one (aside from COLOR'BTNFACE) would be COLOR'WINDOW (5), which is usually white. When combined with the MBF'SUNKEN TYPE flag, this results in a look very similar to the typical Windows "edit" control. You might, for example, display your prompts with the standard BGC default of -1, but display your data with the MBF'SUNKEN option and BGC set to COLOR'WINDOW (or 5). The BEVEL.BAS sample program has been enhanced to illustrate this effect.
Here are a few comparisons of buttons and static text which may help clarify some of the subtleties to be aware of:
| • | FGC and BGC do not (yet?) work for buttons; they only work for static text controls. (Due to internal differences in the way Windows handles the two types of controls, it requires much more effort to adjust the colors of buttons.) |
| • | While buttons are not affected by TAB(-1,9) and TAB(-1,10), static text controls respond to these TCRTs just like regular text. They may even take the dim attribute, allowing them to be protected via TAB(-1,13). You can also delete a static text control merely by doing a TAB(x,y) to the upper left corner of the control. The theory here is to make them act more like normal text, that can be erased merely by TAB(x,y);" "; |
| • | The default alignment for both buttons and static text is centered. (In the case of text, you probably want left justification, so you'll need to add the MBF'LFJUST flag.) |
| • | Ordinary PRINT statements will temporarily overwrite both buttons and static text controls, but will disappear during a display refresh (since buttons and text controls are painted on top of the "screen" window). |
| • | As with buttons, static text controls use a system dialog font whose size is related to your Windows configuration (but not necessarily related to the A-Shell window size.) Although both buttons and static text controls will automatically resize themselves when the window size is changed, the text within them does not resize itself (although it will reformat itself for centering and wrapping purposes). Thus, you may find (as with typical Windows programs), that you'll need to adjust the A-Shell Window size until the text controls and buttons are able to accomodate the text within them. (The worst case scenario here is where you use all upper case characters; these are generally wider in a proportional font than in a fixed size font, and thus may require a larger A-Shell window.) |
| • | Because of the differences between normal text output and static text controls, trying to combine them in the same screen vicinity is not likely to result in a pleasing visual effect. |
| • | You can "layer" static text controls. For example, you can first position a blank rectangle on the screen, and then position smaller text controls on top of it. (This is the only way to get text to "stick" on top of a control.) |
| • | The save area function (e.g. within MSBOXX.SBR, or INMEMO.SBR) will automatically hide any button or static text control that overlaps the area being saved. (This is necessary since otherwise the parts of those controls that were within the box would continue to display on top of the contents of the box.) The hidden controls, however, will be restored when the box area is restored. This makes reasonable sense in the case of buttons, but probably doesn't look that good in the case of text. To get a more Windows-like pop-up window, we've added a new opcode to MSBOXX (see below). |
| • | (Windows) Although you can replace your PRINT statements with MIAMEX,119 calls in order to take advantage of proportional, Windows-style text, this is likely to be tedious and error prone, due to the complexity of the XCALL MIAMEX parameters. To allow you to convert ordinary PRINT statements to proportional text versions more easily, two new PRINT variations have been introduced (in the /X:2 mode of COMPIL): |
TPRINT
DPRINT
TPRINT is intended for "text" (i.e. prompts and other messages), while DPRINT is intended for "data". Both statements support the same syntax and argument options as the standard PRINT statement. (And in a non-GUI environment, both will act just like PRINT.)
TPRINT takes each "token" of its parameter list and turns it into a static text control, as if you had used XCALL MIAMEX,119, with FGC and BGC set to -1.
DPRINT is the same idea, except it specifies BGC=COLOR'WINDOW and adds the MBF'SUNKEN option, so that the output string looks more like an edit control.
Using TPRINT and DPRINT, you might be able to quickly go through a program source, converting it to a proportional, more GUI-like, Windows-style, without sacrificing its ability to work in normal fixed text mode.
You must use the graphics version of the A-Shell/Windows TDV (e.g. PCTDVG instead of PCTDV) or else TPRINT and DPRINT will just act like PRINT. (This makes it convenient for testing.)
PROGRAMMING HINT: In order for programs to format properly in both fixed and proportional fonts, the following guidelines should be observed:
| • | Always use a TAB(x,y) prior to outputting a "token" of text. This will at least ensure that your text prompts and messages always start in a consistent position. (In other words, don't use spaces to position your text.) |
| • | Avoid overwriting parts of existing messages. Instead, try to replace the entire message. (You cannot reliably determine the X,Y coordinates of a particular character within a proportional text string.) |
| • | Add a few extra spaces on the end of text tokens, to provide some "breathing room" for the proportional version of the message to expand if it contains a lot of wide (or capital) letters. For example: |
TPRINT TAB(X,Y);"Vendor Name: "; TPRINT TAB(X,Y);MESSAGE$;" ";
You could do a global replace of your PRINT and ? statements with TPRINT to get a quick idea of how compatible your PRINT statement logic is with proportional fonts.
| • | (Windows) XCALL PCKLST is now implemented using a Windows-style listbox control if you are using one of the graphics terminal drivers (e.g. PCTDVG). The operation is similar to the text version of PCKLST. Current notable differences and limitations: |
| • | The TFCLR (Text Foreground color) field within the MMOCLR structure is the only color parameter that is respected. The background color is hard coded to COLOR'WINDOWS (usually white). |
| • | The top and bottom prompts are currently ignored. (They seem a bit odd looking in the Windows environment. |
863.2
(Windows) A new opcode option has been added to MSBOXX.SBR to display a GUI-style pop-up window: 524288. This has been added to MSBOXX.BSI as BOX'WIN. When specified, and using the GUI version of the driver, it causes the pop-up box to be created using a static text control with the MBF'FRAME option and the standard "button face" background color (generally gray). The "frame" is much thinner than the normal MSBOXX border, allowing the rows and columns which are normally taken by the border to be used for text if so desired. This style of box is the only kind that can overlap other controls (without causing the underlying controls to have to be hidden). However, if you use this style of box, you should only print within it using TPRINT, DPRINT, or MIAMEX,119. Any other kind of output will "print through" to the underlying screen layer and not be removed when the box is removed.
863.3
(Windows) MIAMEX,91 (set system background color) has been enhanced to allow you to associate one of your 16 palette colors with two other Windows system colors: "window color" (typically white) and "text color" (typically black):
XCALL MIAMEX,91,OP,SYSBGC{,SYSWINC{,SYSTXTC}}
The SYSWINC (0-7) applies to one of the background colors in the color palette, while SYSTXTC (0-5) refers to one of the foreground colors.
The advantage of using these colors is that the user can then adjust your color scheme using the Control Panel desktop applet.
It is preferable to use this method of associating a background color number with the "system gray" color, rather than simply trying to pick a suitable gray from the color palette, because this not only guarantees that you get exactly the right gray, but also allows certain A-Shell routines to optimize themselves by using the system palette. Consequently, the recommendation would be to add code to execute MIAMEX,91 in your startup routine. Or at the very least add a SET TERM SYSBCOLOR ## command to your startup command file.
863.4
(Windows) The external leading between rows has been increased by one pixel, to a skosh more room for the edges of controls to fix in between lines of text. This might have the effect of shrinking your font size for a given window size, but is unlikely to be that noticeable. (We might make this a user-definable setting.)
