When switching from fixed to proportional text, you are likely to run into problems with columns not aligning as they used to. This is due to the fact that with proportional fonts, character widths vary depending on the character. In particularly, the space character is very thin compared to most others, especially the capital letters (like W). However, because A-Shell continues to use the same row/col grid for Tab(x,y) commands, you can usually solve your alignment problems by following these guidelines:
• 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.)
• To overwrite an existing text object, you can simply Tab(X,Y) to the start of it and output a new text string. (You might want to pad the string with sufficient spaces so that in the case of text mode, it would fully overwrite the 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$;" ";
One situation you may run into is where you use a combination of Tab(x,y) with some spaces to align fields like this:
1. Name:
Addr:
12. Parish:
Postal code:
Assuming the last two items were variables (i.e. depending on some other flag, you might display "City", or "Borough" instead of "Parish", and "Zip Code" instead of "Postal Code"), then you might have created the above display with code like the following:
PRINT TAB(10,5);" 1. Name:"
PRINT TAB(11,5);" Addr:"
PRINT TAB(12,5);"12. ";CITY$
PRINT TAB(13,9);PHONE$
This works because the spaces occupy the same width as the numeric digits and the period, so in all cases the main part of the label starts in column 9. But if we convert these PRINT statements to TPRINT (or use SET AUTOTPRINT), they will no longer line up because spaces, digits, and periods all have different widths in the proportional font world. Following the guidelines give above, the ideal solution would be to recode this as:
TPRINT TAB(10,5);" 1. ";TAB(10,9);"Name:"
TPRINT TAB(11,5);" ";TAB(11,9);"Addr:"
TPRINT TAB(12,5);"12. ";TAB(12,9);CITY$
TPRINT TAB(13,5);" ";TAB(13,9);PHONE$
But unfortunately that involves a lot of retyping. Slightly less retyping would be this solution:
TPRINT TAB(10,5);" 1. ";"Name:"
TPRINT TAB(11,5);" ";"Addr:"
TPRINT TAB(12,5);"12. ";CITY$
TPRINT TAB(13,5);" ";PHONE$
The above solution works because each of the TPRINT statements has two arguments. The position of the second argument is calculated based on the number of characters in the first (which is 4 in each case), regardless of the fact that those characters will occupy different widths when rendered using a proportional font. So the result is equivalent to the previous example, where the Tab(x,9) was explicit.
But even this may be a lot of work if you have a lot of screens like this. In the case, you may want to use the shortcut of adding OPTIONS=GUI_SPC_IND to miame.ini. This causes any string which contains leading spaces, or a combination of leading spaces, numeric, digits, a period, and one or more spaces, to be output as if it was a separate print object from the rest of the string. In other words:
PRINT TAB(10,5);" 1. Name:
Would be interpreted as if it had been coded as:
PRINT TAB(10,5);" 1. ";"Name:"
This will generally result in the kind of alignment you were probably hoping for. (However, unless you know you have this problem, we don’t recommend just turning on this switch as a precautionary measure, because it increases screen complexity which may lead to some other undesirable side-effect.)