Static text controls are the simplest kind of controls, consisting just of a text string formatted within a rectangular area, with an optional click notification. You may adjust the font and color, but in most cases, will just want to use the default font and color to get the most uniform, Windows-like look. Since static text controls correspond to simple PRINT statements in the text model, the following PRINT statement:

PRINT TAB(10,5);"Customer Name:";

would correspond to this static text object:

xcall AUI, AUI_CONTROL, CTLOP_INFO, ID, "Customer Name:", MBST_ENABLE, MBF_STATIC + MBF_LFJUST, "", "", STATUS, 10, 5, 10, 19

This probably seems like overkill, but before addressing that, we should first clarify some subtle distinctions between the standard text and static text control implementations.

• Because the text and GUI layers use the same coordinate system, in both cases, the message starts in the same location (row 10, column 5). Also, since we set the ending column of the GUI version to 19, both will occupy the same amount of space. (This fact is important in converting from the fixed pitch to proportional font layouts. But, although the static text control occupies the same amount of space as the text counterpart, some of that space may appear blank (depending on the size of the font and how much difference there is between the fixed and proportional font metrics for this particular string. Typically, lower case characters will take up much less space in a proportional font than in a fixed pitch font, but the reverse may be true with all upper case. So if your text prompts are all upper case, you may need to allow more room (or convert them to lower case, or add the font parameters to the AUI CONTROL call to adjust the font to fit.)

• Because the proportional version of the character string will not appear to take up as much space as the fixed pitch text version, attempts to position adjacent messages based on columnar calculations will not work very well in the proportional environment. See the section on Preparing to Convert from Text to GUI for further comments on this.

• In the above example, we did not define a command to be associated with clicking on this static text object, but we easily could, in which case the static text object acts like a button. We can also define a tooltip, although this requires that there also be a click command string associated. You can use "VK_NULL" (see Virtual Key Symbolic Names) to define a click command that does nothing, just so you can have a tooltip.)

• Although the static text object exists in a layer above the standard text layer (and thus would obscure anything below it), as a convenience, it may be deleted by the same kinds of PRINT TAB operations that would delete the text version.

If your screen prompts are parameterized (loaded from a file and output using a centralized routine), then converting from the PRINT version to the AUI CONTROL version will be simple. But if you have thousands of literal PRINT statements throughout your programs, you might want to consider one of the following shortcuts:

• PRINT statements may be replaced one-to-one with TPRINT statements, which, when compiled with the /X:2 switch, are equivalent to the AUI CONTROL shown above. That is, every segment or argument to a TPRINT statement will be converted to a separate static text control starting in the position it would have in the fixed pitch environment, and occupying the same frame space (although likely with some trailing space at the right edge of the frame.) When compiled without /X:2, TPRINT statements revert to PRINT.

• PRINT statements may also be replaced with DPRINT statements, which are equivalent to TPRINT except which add the MBF_SUNKEN effect. (In general, this works well for printing data to separate it from other text.)

• SET AUTOTPRINT may be used prior to running a program to automatically treat all PRINT statements like TPRINT. This method provides the fastest way to see how well your screen layouts behave with proportional fonts.

• PRINT TAB(-10,20); TEXT$; chr(127) is equivalent to TPRINT TEXT$. The advantage of the PRINT TAB(-10,20) approach is that it eliminates any compiler dependency (i.e. you could compile under AMOS, or use the same RUN under both AMOS and A-Shell). You would probably need to modify your AMOS terminal driver to filter out the trailing chr(127), or perhaps ideally, to send the necessary escape sequence so that an ATE client could understand the command just as A-Shell/Windows would have.

All of the above alternatives to the AUI CONTROL class for static text assume left justification. TAB(-10,20) also supports a second argument consisting of T (TPRINT) or D (DPRINT) plus L (left), C (center), or R (right) which give you some more flexibility.