866.1
(Windows) New MIAMEX function:
XCALL MIAMEX,126,OP,SROW,SCOL,EROW,ECOL,BGC
MX_SINK causes the specified box to be "sunk" or "unsunk", based on OP (1 to sink, 0 to unsink). This is the same routine used by INFLD to give the field being editing the appearance of being slightly sunken. You can also get this effect by using the MBF'SUNKEN flag with MIAMEX,119 (see edit 863 below) to create a static text control with that style, but in that case, you can't freely write on top of the control. With MIAMEX 126, the effect does not conflict with character-level I/O to that screen area (which is why it works with INFLD).
866.2
(Windows) To allow easier experimentation with the new proportional font capability without having to change your PRINT statements to TPRINT or DPRINT, or to MIAMEX,119 commands, A-Shell/Windows now supports a primitive "manifest" file mechanism. The "manifest" is a text file whose name and location match the RUN file, but whose extension is MFT. If such a file exists when the RUN file is launched, it will be processed for lines consisting of the following:
;(comments are any line whose first char is not a number)
<ROW>,<COL>,<LEN>,<TYPE>
<ROW>,<COL>,<LEN>,<TYPE>
etc.
<ROW>,<COL> and <LEN> together specify the location on the screen of text that you would like to have automatically converted to use proportional text.
<TYPE> specifies a combination of the letters T (text), D (data), L (left justify), R (right justify), and C (center).
For example:
10,1,20,TL
10,30,15,DR
This would cause any PRINT statement that began on row 10 within the column range 1 to 20, to be replaced with left justified static text.
The second line would cause any PRINT statement that began on row 10 within the column range 30 to 44 to be replaced with right justified "data-style" (sunken using the current Window color) text.
Note that this scheme is not intended for production use and is likely to evolve (or devolve) rapidly. It is only here to simplify experimenting with the proportional font look. Also note that the coordinates and length have no effect on the actual coordinates and length of the static text control created. It only affects whether a particular PRINT statement is subject to being converted to static proportional text automatically (based on where the cursor is at the start of the PRINT statement token.)
For example, using the above manifest example, consider the following statement:
PRINT TAB(10,5);"Name: ";TAB(10,35);"Jack"
Because the first token ("Name") starts within the range of the first line in the MFT file, it would effectively be interpreted as:
TPRINT TAB(10,5);"Name: ";
Similarly, the second part of the PRINT statement would be interpreted as:
DPRINT TAB(10,35);"Jack"
(Except that the DPRINT statement doesn't allow for right or center justification, whereas the manifest will take care of this as well.)
These statements would create a left justified text control using the current screen foreground/background colors for "Name: ", and a right justified "data" text control containing "Jack". The data control would use the current screen foreground, but the standard Windows window color (generally white) for the background.
At this point, the MFT mechanism is very primitive, and it isn't clear whether it should or will be developed into something more useful in an actual production environment. (Feel free to submit suggestions if so inclined.)
