Absolutely not. You should never use @CONSOLEB in a tab window -- there's no way for TCMD to know when a console changes its buffer.Are @CONSOLEB and TCMD supposed to get along? TCMD shows a new console buffer but only momentarily, and any activity thereafter causes a crash in the Console Window Host.
I've been experimenting with different ways of displaying F1/Ctrl-F1 help in a plugin. I spent a long time working on showing it below the command line with a continue prompt which erased it. But that fails miserably when the command line in-progress is near the bottom of the console screen buffer (and I'm pretty sure I shouldn't be scrolling when you're keeping track of the position of the command line).Nor is there any reason to do so in TCC -- why were you attempting it?
I tried that too (and might get back to it). With a thread, I can pop a message box which will let the user continue working at the command line. I couldn't figure out a way to get it to stay on top of TCC without staying on top of everything else. And many of my commands (9 in this plugin alone) don't have an easily accessible quick help that can be specified as the text for a message box; they generate it on the fly. For those, my HELP calls "plugin_command /?".Why don't you just pop up a GUI window to handle everything?
SET buf1=%@CONSOLEB[-1] SET buf2=%@consoleb ALIAS @@Shift-F1 `ECHO %@CONSOLEB[%@IF[%@CONSOLEB[-1] == %buf2,%buf1,%buf2]] > NUL`
Do you need a second buffer for that? It seems to me that you could party on the original console buffer however you like, provided you back up the original text and color data before you begin and restore it afterwards. I haven't tried it myself, though.You know ... alternate console screen buffers can be convenient and easy to use. With just a few lines in TCSTART, I can make an alternate buffer and a simple way of switching between the two. And that could be made more elaborate.
It would be easy, but it won't work -- TCMD can't access the buffer after it's been changed, regardless of whether it's been notified. The only way to support that is to inject dll's into every console session. (Which would result in TCMD being blocked by most antivirus apps.)It would seem easy to have @CONSOLEB inform TCMD (if necessary) of a buffer change (not for my sake and NITV). But I wonder how easy it would be for TCMD to handle it!
Yeah, a little bit of snooping revealed that that's exactly what Console2 (which handles changes of buffer well) does, inject a DLL.It would be easy, but it won't work -- TCMD can't access the buffer after it's been changed, regardless of whether it's been notified. The only way to support that is to inject dll's into every console session. (Which would result in TCMD being blocked by most antivirus apps.)