how to ECHO in opposite colors?

Jun 3, 2008
Temecula, CA
In my TCC window (v16.03), I'd like to be able to have a function that will take an input string and display the text and background in opposite colors of what it normally is. For example, my TCC window uses bright cyan letters on a blue background. This function should display the text in blue letters on a bright cyan background. Ideally it should be able to do it interspersed within a single line, like:


I would imagine something like: ECHO This is bright cyan on blue. %@reversecolor[This is blue on bright cyan.] This is bright cyan on blue again.

Or maybe instead of %@reversecolor[], it could be %@echocolor[foreground, background, text]. Then it would be: ECHO This is bright cyan on blue. %@echocolor[blue, brightcyan, This is blue on bright cyan.] This is bright cyan on blue again.

Is this possible?
If you want to embed color changes within a command line like that, I think you'll have to use ANSI sequences. (Functions return strings, and strings don't have colors per se. But you could create functions, or variables, which return ANSI codes.)
SCRPUT might be useful sometimes, but it has limitations.


A plugin to add the necessary ANSI escape sequences wasn't too hard.


I know virtually nothing about ANSI sequences. But as you can see above, that has the side effect of not restoring the window to its prior colors. I did notice that if I executed the COLOR command immediately afterward, the colors were properly restored. But I couldn't figure out how to fit that within the alias. And I wouldn't want it just to use black on white, I would want it to use the opposite of the current colors. For example, most of my TCC windows use bright cyan on blue, so I would want the reverse to use blue on bright cyan. But ideally the alias would use the current FG and BG, not just hard-coded to blue on bright cyan.
"^e[0m" should restore the default colors. I know nothing about Win10's builtin ANSI support, but in Win7, it's a good idea to have TCC's colors (OPTION dialog) agree with the console's colors (console properties).

In your pic, you didn't get the reverse of light blue on dark blue. I think there may be two notions of what the default colors are.

Just curious. I guess you must be inserting ANSI sequences at both ends of the string -- reverse video at the front, and restore at the end.

(Since all functions are expanded before the command is executed, dynamically changing settings like TCC's internal colors in a function can yield confusing results.)
Just curious. I guess you must be inserting ANSI sequences at both ends of the string -- reverse video at the front, and restore at the end.
Yup, exactly. At the time, I had forgotten about ^e[7m. That'll make it quite a bit easier, smaller, faster
Trying to make sense of a bunch of this stuff. (BTW, I'm running Win7-64, not Win10.)

OK, for my TCC options, I have the following:


So whatever the console window's properties are, TCC should inherit them.


So we can see that the console's defaults are bright cyan on blue.

But regardless, after using the function, the screen should return to whatever we've set it to - either the default, if we didn't set it, or to whatever we might have overridden the default with the COLOR command.
I dunno. I have always told TCC the same FG and BG that I tell the console, and here, that also agrees with the console defaults (system menu\defaults, and stored in HKCU\Console). Those defaults are usually WHI on BLA (which you're seeing). I'd be very surprised if TCC were using them. Perhaps Rex will chime in with an explanation of what's going on.
Well, I will say that I nearly always do have my TCC window using the same FG and BG values as the console defaults. However, they aren't WHI on BLA. Maybe the problem is that the ANSI implementation doesn't use the console defaults, but instead assumes the "normal" defaults and uses the reverse of them for its reverse implementation.

Similar threads