Screen colors

Hi George -

There are several things going on here, so I'll try to explain them one at a time.

First, Visual Styles is simply a way to associate a border style and foreground / background color combination with a visual attribute (dim, reverse, etc.) Basically, you can assign Dim to have an Inset border style, Reverse to have a Flat style, Underline gets a Raised style, etc.

The color assignment is basically the same as it has been with earlier versions of AccuTerm, except that there are now some color schemes that change some of the standard AccuTerm palette colors to system colors (as assigned in the Display properties, Appearance tab). For example, black is remapped to "Window Text", white is remapped to "Window Background", etc.

Clicking the "Classic Windows" or "Windows XP" under "Visual Styles" simply sets up the palette using appropriate system colors and sets a color combination and border style for each attribute, ensures that "Border Style" is not set to "None" and disables true underlining. You can customize any of the attributes to suit your own application style.

The way Visual Styles is used is to simply display data using an appropriate attribute. For example, using "Classic Windows", text displayed in the Reverse attribute will appear as if it were a Windows text box, using the same colors and border style used by other Windows programs.

Now, to answer the question of why changing the attribute changes everything on the screen: this is how a real Viewpoint terminal works, at least regarding attributes. The old Viewpoint A2 terminal uses a single bit in each character as a "tag". Each tagged character is displayed in the currently selected visual attribute. When the current attribute is changed, say from Reverse to Dim, all tagged characters on the screen are redisplayed in the new attribute, Dim in this example. We call this "tagged" attributes in the AccuTerm documentation.

When using the Viewpoint A2 Enhanced emulation (or the Wyse 50 emulation), you can use both "tagged" attributes and "embedded" attributes. In these emulations, the tag bit is also used to indicate a "protected" character.

"Embedded" attributes take a character position on the screen. The "embedded attribute" character itself is displayed as a blank without any attribute. All the characters the follow the "embedded attribute" character are displayed using that attribute, at least until another "embedded attribute" character is encountered. This continues to the end of the screen. This is why Wyse terminals, unless carefully programmed, will flicker.

Typical terminal coding would suggest that you do something like:

NORMAL = @(-14)

REVERSE = @(-13)

PRINT @(10,7):REVERSE:'This text is in reverse video':NORMAL

When you run this code, you may see the screen flicker. This is because when the terminal receives the REVERSE code, it changes the attribute of all characters from the cursor position to the end of the screen to reverse video. Then the text is displayed (in reverse video). Finally, when the terminal receives the NORMAL code, it changes the attribute of all characters from the cursor position to the end of the screen to normal video. During the time after receipt of the REVERSE code but before the NORMAL code, the screen is in reverse video from position @(10,7) to the end of screen. When the NORMAL code is received the portion of the screen from @(40,7) to end of screen is changed back to normal video, causing the screen to flicker.

Flickering is not as much of a problem with fast network connections as it used to be with serial ports, but it still can occur and looks very unprofessional.

The correct way to program for this kind of terminal is to print the attribute codes in reverse order: print the NORMAL code first, then the REVERSE code:

NORMAL = @(-14)

REVERSE = @(-13)

PRINT @(40,7):NORMAL:@(10,7):REVERSE:'This text is in reverse video'

This resolves the flickering problem because the attribute changes only until another attribute is encountered. In this example, NORMAL is at the end of the field, so when the REVERSE code is received by the terminal, only the area from the cursor position @(10,7) to the next attribute @(40,7) is changed to reverse video.

To further confuse the situation, when Wyse released the Wyse 60 terminal, they abandoned the "embedded attributes", and switched to "character attributes", which required two whole bytes for each character, instead of only a single byte. "Character attributes" are similar to "tagged attributes" in that as each character is displayed, it takes the current attribute in effect. It is different in that changing the current attribute does not affect anything already dispalyed. "Character attributes" do not occupy a screen position like "embedded attributes" so you have more freedom in screen layout. And there is no flickering when using "character attributes".

Now for some fun: when ADDS released the 4000 series of terminals, they attempted to include the same features as a Wyse 50 running in Viewpoint/A2 mode with "Enhance" turned on (hence "Viewpoint A2 Enhanced"). However, they must have recognized that "embedded attributes" were not a good solution, and while supported (sort of), they added "character attributes" as well. A different Escape sequence was used for the "character attributes", so the 4000 actually supports all three attribute schemes.

The current version of AccuTerm 2K2 fully supports all three attribute schemes in the Viewpoint A2 Enhanced emulation. If possible, use the ADDS 4000 "character attributes". The escape sequence for character attribues is ESC:'g':ATTR where ATTR is the same as the Wyse attributes shown in Appendix A of the Programmers Guide. This is basically the same sequence as used by Wyse 60, except for the lower-case "g" rather than upper-case "G".

Hope this explanation was not too confusing!

Thanks,

Pete