I have AT 12.18 set up to show me black text on a white background (Appearance: Application Defaults, Foreground=Black, Background=White). When I'm telneting to a system and they blast me lots of traffic, occasionally refreshing the screen, the display will sometimes switch to a black background with white text and remain that way.
I tried fiddling with Appearance setting but couldn't find a way via that pane to switch back to my preferred color scheme (Black text on white background) but *eventually* found a way == disconnect then reconnect to the telent session, to get back to my desired settings.
But how is the remote session overriding my preferred Appearance, and how I can it stop it from doing that so I don't have to do the disconnect/reconnect dance?
The remote host can change the terminal colors through escape sequences. This is common for example when listing out files in the shell, where different file types (folders) may display with a different color. It's also common when a text editor uses color for syntax highlighting while editing code, etc.... Well-behaved servers should switch colors when they need to, but return to your defaults when they're done. Ill-behaved ones may not play that nice. Once the server changes the colors, Absolute will NOT just 'switch back' without being told to.
There are a few conditions where colors commonly get wacky.... For example, catting binary data to the screen. When you say the other system 'blasts you lots of traffic', I wonder if this isn't it.
Generally, typing 'reset' at the shell will return things to normal without having to disconnect/reconnect.
If you believe something is going WRONG, you could send me a session logfile and I can take a look. In Absolute:
1. File->Open Log
2. Connect to the server which blasts 'lots of data' until you see the problem arise
3. File->Close log
4. zip and email the log to me.
Not, it's not a binary dump. The system at the other end is just dumping a ton of console data on boot or after running specific system commands. But part way thru the screen switches to black + white text and stays there, unless & until I manually disconnect then reconnect. Very annoying.
Let's assume that that the server isn't "well behaved." == is sending such escape seqs intentionally or because there are bursts of gibberish. I don't think it's unreasonable to set AT to ignore any color changes and leave things along even if the server would "like" to force (request...) a color change. A "dumber" telnet program like PuTTY does that. Isn't there a way to make AT "dumber"?
I’m sure I can do something to help. At the very least an option to ‘ignore color changes from server’ would work.
if you can send me the session log, that would first give me a chance to review the data and see if maybe I’m doing something wrong.
You say putty does not have this problem? If I have the log data I can try to figure out why.
@bpence Where does the "Session Log" get saved? I can do an a File/Open Log" to see if AbsoluteTelnetLog.txt creates something there (there's no such file based on the last time I ran the tool). Do I have to do something to force-enable logging at a known location.
It's not "fun" to try to recreate this -- it happens when the sever end is dumping lots of output, switches mode to boot into a BIOS or PXE boot screen, etc. At best I can keep an eye on it and then freeze & upload the AT log the next time I notice it.
Seems like "an option to ‘ignore color changes from server’" is the most straight forward way to prevent it.
By default, when you 'open log', AbsoluteTelnetLog.txt is created in your documents folder.
Then just 'keep an eye on it' and when you notice the problem, that's when you File->Close Log and send the log to me.
'ignore color changes from server' is probably the way I'm headed, but I don't like to implement in the blind. The data you send me will be how I verify the root cause and confirm the solution actually works. It's possible there are other solutions as well, so I need to poke around to make sure I land on the best one.
I generated the log, but when I took a look at it I realized it's just the full console dump, not something that has just *internal* AbsTel information such as setup/config, codes, etc.. So I don't think it's something I can appropriately post on a public forum -- it has info that would be considered proprietary.
So instead I took a small screenshot at the point where my console, initially showing black-text-on-white-background, auto-switched to white-text-on-black-background (much harder to read). After which it permanently remained that way, until & unless I disconnected then connected the session.
I do occasionally use other background colors (e.g. black text on light green, light blue, light yellow, light pink) to make it easier to distinguish among multiple opened & active tabs as I move among them. But those get overwritten (to white text on black background) the same way.
@goawest , unless you can whittle it down to the offending parts (using split?), I'll have to take an educated guess. Stay tuned
I don't know what deep dark secret you think I'm keeping from you, but I'm pretty accurately describing what's going on. When I boot up the connected system I initially see black-text-on-white-background the AT Appearance I've set, which continues for a while. But eventually the system jumps to a screen (a BIOS or BMC console, all black with white text), and after it continues streaming it's all white-text-on-black-background. I've attached another pic after at the transition (although it doesn't show that momentary BIOS/BMC screen).
I'll also attach a screenshot of the log -- even thought it's saved as a *.txt file, my editor sees it as a binary-hex file and displays it as shown. I don't know if there are any control-chars etc. in there that would tell you anything. Again, it's got a lot of details that are too proprietary to attach here. If you wanted to look at at during a private Zoom or WebEx session we could do that, as well as letting you live-watch the system boot as the AT screens change (WoB to BoW), we could do that -- nothing beats "seeing for yourself."
And a short screenshot of the "*.txt == binary-hex file" log.
No secrets, but the devil is in the details (the logfile). It's the difference between KNOWING and GUESSING. But I'm a pretty good guesser, so we can do this a different way
If you're not comfortable sending the logfile, you shouldn't.
I'm working on an updated install and will let you know in just a bit when it's ready to try.
Ok.... I have an update. This includes an option on the options/properties/appearance/color called 'allow server to change colors' which is initially ENABLED, but can be disable. If this doesn't work, we'll have to discuss a zoom call or some other way to get a safe subset or redacted version of the logfile.
Disable the option, SAVE the connection file and try again.
Check out the beta page, read the descriptions, download and install.
There are a few other changes in-flight. This may not be the FINAL iteration of 13.11.
https://www.celestialsoftware.net/beta-testing/
Brian
Have you had a chance to try the update?
I did have to jump thru an initial hoop to request a new demo license since my paid license is now over year old. Then did the install update, overwriting the previous one ###.
Nope on the fix. For a moment I thought the black-background switch was gone, but it immediately came back -- first as black lines, then as a PXE boot window, then as an endless scrolling pane of console output with white-text-on-black. See attached accumulated screenshots.
### Another long-standing nit I'll mention == I don't think you need to kill Windows Explorer when installing an AbsTelnet update. I had forgotten that your install process always does that, requiring me to then clean up some stuff and manually kill & restart a running program that can't handle that. I'm not using any other programs that do that when installing an update.
Oops, dumb me. I missed the fact that I had to intentionally take action (disable the 'allow server to change colors') to get the new functionality. On the plus side, I just tested the *negative* case and we know your fix didn't *break* anything :-).
I'll repeat the test when I'm next at work, next Tuesday, and report back.