ATE and A-Shell support a "three dimensional" form of the A-BASIC PRINT Tab command:
? TAB(row, col, Z); ...
This is equivalent to the standard "2D" form of PRINT TAB(row,col), with the addition of a third argument, Z, which is used as an index into a table of text attributes that can affect the appearance of anything output with this PRINT command (i.e., color, font, size, etc.). Although this feature does not make anything new possible, it does offer a very flexible tool for migrating legacy text programs to a GUI (or perhaps just a more colorful) environment.
The theory is that you would convert existing Tab(row,col) statements to the Tab(row,col,Z) format, replacing Z with one or more variables that correspond to the nature of the text being displayed. Having done that, you can then define a set of display attributes for each of the types, through a series of calls to MX_DEFTABXYZ, whose syntax is:
xcall MIAMEX, MX_DEFTABXYZ, sts, Z, fgc, bgc, ptype, fontattr, fontscale, fontface,...
The XCALL allows you to associate a variety of text attributes with the value Z, so that when you use PRINT TAB(X,Y,Z);VAR$, A-Shell will apply the specified attributes to the display of VAR$. See MX_DEFTABXYZ (154) in the A-Shell XCALL Reference for more information. Use multiple calls to the function, one per text type or Z value.
Comments
You must compile with the /X:2 switch to enable support for 3D Tabs. Otherwise you will get a syntax error, unless you use /RC, in which case TAB(X,Y,Z) will compile as if it were TAB(X,Y). This allows you to compile down for backwards compatibility. Programs using TAB(X,Y,Z) and compiled with /X:2 will not be compatible with prior versions of RUN.
You can also disable the 3D Tab behavior at runtime by adding OPTIONS=NO3DTAB to the miame.ini file. This might be useful if you want to quickly revert to the old behavior even with programs compiled for the new behavior. Of course, you could also achieve the same effect by disabling your MIAMEX,MX_DEFTABXYZ calls.
It has been left as an exercise for the application programmer (that's you!) to come up with a user interface to allow individual users to define their own attributes for the various Z values you decide to use.
Example
As an example of how to use this feature in practice, let's say that after analyzing your application, you decide that there are really only five main types of text output:
1=headers
2=field labels
3=data
4=aux data (legends, helpful messages relating to data)
5=warning messages
You might then define five symbolic constants representing these types:
| define TBX_HDR = 1 | ! headers |
| define TBX_LBL = 2 | ! labels |
| define TBX_DTA = 3 | ! data |
| define TBX_AUX = 4 | ! aux |
| define TBX_WRN = 5 | ! warnings |
Then you would go through your programs converting existing TAB(row,col) to TAB(row,col,Z) depending on the nature of the PRINT statement. For example:
SCREEN'HEADER:
PRINT TAB(1,1,TBX_HDR);"Customer Maintenance"
...
SCREEN'BACKGROUND:
PRINT TAB(5,5,TBX_LBL);"Name: "
PRINT TAB(6,5,TBX_LBL);"Address:"
...
DISPLAY'DATA:
PRINT TAB(5,20,TBX_DTA);CUS'NAME
PRINT TAB(6,20,TBX_DTA);CUS'ADDR1
...
At runtime, you would issue five MX_DEFTABXYZ calls to define attributes for the five types of text, assuming you wanted to alter the appearance of that type of text from its original style.
Although this could be a tedious job, there are a several advantages to this approach versus some other methods of migrating existing code, such as replacing PRINT statements with TPRINT/DPRINT/EPRINT or TAB(-10,20) or AUI_CONTROL statements:
| • | You might be able to write a filter program to automate the conversion, by looking at the nature of the things being printed. (Literal strings would usually be label text, unless perhaps on row 1 or 2; variables would be data, etc.) What can't be handled by your filter can probably be handled by a very junior programmer, since the cost of making a mistake is purely aesthetic. |
| • | Until you activate the feature by defining attributes, the 3D Tabs continue to work just like the old 2D Tabs. |
| • | The /RC switch will compile 3D Tabs as if they were 2D Tabs (ignoring the 3rd parameter), providing a path to backwards compatibility. |
| • | With the new 3D Tabs in place, you are now in a position to allow a great deal of flexibility at runtime in deciding which attributes to use. Depending on the situation (user, site, stock market, etc) you can decide to leave the display in legacy text mode but apply different colors to the different types of text. Or you can go all the way and convert them to GUI text objects using various different styles, font attributes, etc. |
See Also
A simple sample program, TABXYZ in EXLIB:[908,38], illustrates the feature.
