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.
@CONSOLEB and TCMD?
- Thread starter vefatica
- Start date
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.
Nor is there any reason to do so in TCC -- why were you attempting it?
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).
My latest attempt shows the F1 help in an alternate console screen buffer with a continue prompt when _TCTAB is 0 (that was rather easy with the help of @CONSOLEB), and the old way when _TCTAB is 1 (below the command line, no erasing, which, as I said, is unsatisfactory when near the bottom of the buffer).
Is there a way I can cause the prompt and command-line-in-progress to be shown again, after the help message ... i.e., in a different place?
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 /?".
I never considered the F1 mechanism when I wrote the HELP function. And in many years, I never used F1 for a plugin. A recent thread was the first indication that it was rather ugly.
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 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!
Code:
SET buf1=%@CONSOLEB[-1]
SET buf2=%@consoleb[0]
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.
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.)
Yeah, a little bit of snooping revealed that that's exactly what Console2 (which handles changes of buffer well) does, inject a DLL.
I'm working on saving, erasing, and restoring the the current visible portion of the buffer. Is that how the old dir/command history in-console pop-ups worked?
Similar threads
