Text Message Tokenization
One of the most obvious differences between traditional legacy text applications and Windows GUI applications is the use of fixed pitch vs. proportional fonts. The obvious problem with proportional fonts is that they take up variable amounts of space depending on the individual character widths. In order for a screen layout to translate easily from fixed pitch to proportional (and back again), the most important factor is the degree to which the text messages are "tokenized". If each text message (field prompt, column header, advisory tip, etc.) is individually positioned by a Tab(x,y), without relying on spaces for positioning, this will make the conversion much easier. Any use of spaces for positioning (relying on the fact that a space occupies one column just like any other character in a fixed pitch font) will not translate well to proportional fonts (where spaces are about half the width of a typical character.) For example:
PRINT TAB(5,5);"Customer Name"; TAB(5,45);"Home Phone";
PRINT TAB(6,5);"Address"; TAB(6,45);"Bus. Phone";
PRINT TAB(7,5);"City"; TAB(7,45);"Fax";
The example above works well with both fixed pitch and proportional fonts. However, the example below will not work well at all, because the prompts in the right hand column which line up in a fixed pitch will not work at all in a proportional font. Not only won’t the column line up, but it will appear much closer to the first column because proportional font spaces are much slimmer than fixed pitch spaces.
PRINT TAB(5,5);"Customer Name Home Phone";
PRINT TAB(6,5);"Address Bus. Phone";
PRINT TAB(7,5);"City Fax";
With a proportional font, the above statements will appear something like this:
Customer Name Home Phone
Address Bus. Phone
City Fax
Aside from examining your source code, a quick way of sizing up how serious a problem you have in this area would be to use the SET AUTOTPRINT feature, which causes all subsequent PRINT statement output to be rendered in a proportional font.
Subtopics
