Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

[Bug Report] TCC freezes using "list" command and "F" to find

R

RobN

Feb
6
0
When I use the "list" command to look at a file in TCC.exe, then use "F" to find it will find the first match, but then the window will freeze permanently. It is necessary to close the window with "X" to get past it.
I have tested this with TCMD.exe and the problem does not happen there, only with TCC. I have also tested this on files big and small, simple search patterns too. I haven't found a case it doesn't lock up.

TCC 32.10.21 x64 Windows 11 [Version 10.0.22631.3880]
TCC Build 21 Windows 11 Build 22631
 
Works here correctly ...

Microsoft Windows 10 Pro x64 [19045.4717] [22H2] [de-CH] TCMD 32.10.21 x64

Is that the case with different (all) files (also check utf-8 etc.)?
 
RobN said:
When I use the "list" command to look at a file in TCC.exe, then use "F" to find it will find the first match, but then the window will freeze permanently. It is necessary to close the window with "X" to get past it.
I have tested this with TCMD.exe and the problem does not happen there, only with TCC. I have also tested this on files big and small, simple search patterns too. I haven't found a case it doesn't lock up.

TCC 32.10.21 x64 Windows 11 [Version 10.0.22631.3880]
TCC Build 21 Windows 11 Build 22631
Click to expand...

Not reproducible here.

Not sure what you mean about it working in TCMD - LIST is only in TCC. Are you saying that when you run TCC in a TCMD tab window everything works?

Note that LIST is deprecated / obsolete -- it has been replaced by the far more capable VIEW.
 
Tested over here, no problems whatsoever so far.


Also, LIST might be obsolete and less capable than VIEW, but... it runs on the same TCC console, which is what one is using instead of creating a new window (with usually a different color scheme, font, size, etc.). That omission of context switching makes it worth to continue using LIST at least for small files. IMNAAHO.
 
Is it possible that the popup "Find" dialog is popping up underneath the console window? Or entirely off-screen?

For that matter, are you running TCC in a regular console window? Or in a Windows Terminal window? Or something even odder, like Console2 or ConEmu?
 
Last edited:
mfarah said:
Also, LIST might be obsolete and less capable than VIEW, but... it runs on the same TCC console, which is what one is using instead of creating a new window (with usually a different color scheme, font, size, etc.). That omission of context switching makes it worth to continue using LIST at least for small files. IMNAAHO.
Click to expand...
Agree completely. I use LIST all the time and never use VIEW. If I am going to be working with a file, I use my text editor.
 
Here's some new information:
  • I am launching TCC.exe directly from a shortcut on my start bar, no command line arguments, and it's in its own terminal window (I believe it's a windows terminal window).
  • Use "list" on "updater.ini" in the TCMD folder.
  • Hit "F" to search for a term in here, like "AppDir". It jumps to that term, but further keypresses do not work (eg. "ESC" to exit, "N" for next find, etc)
  • The new infromation: The terminal window is losing focus. If I click back into the terminal window, then it's not frozen (eg. "ESC" and "N" work)
  • The find dialog box (where you type in the search term) is NOT present on the screen until I click back on the terminal window, and after I click on the terminal window it's partially off screen (straddling my monitors and off the top of the screen).
  • I run two 4k (3840x2160) monitors at 125% scale. I just tried 100% scale hoping that might explain the find box partially off screen, but it did not change the behavior.

Also "list" works in both TCC.exe and TCMD.exe, but only "TCC.exe" does it lose focus when you use "F" for find. In TCMD.exe it does not lose focus.

So I'd like to revise my report that this isn't a hang, but rather a change of focus issue. This is new behavior vs. old versions of TCC that I've used for years. Old versions keep the focus on the terminal window after you find.

To respond to "view" vs "list". I've been aware of view for years and have tried to use it on many occasions, but to this day "list" remains my preference. There are several small reasons that I prefer it:
  • It stays in the same window as I am working. No need to shift my eyes to another window or grab the mouse to move things around. Also it's in the same font/coloring so no need to change visual context.
  • When you "esc" out of it, it leaves the last page on the screen. I use this all the time, because I can refer back without having to type list again, it's in scroll history.
  • "F" and "N" for find and next, instead of "Ctrl-F" and "Ctrl-N" (this is minor but it's part of my muscle memory).

I use "list" to pop in and out of a file to get quick information I need. I hope this is not deprecated, and that you can fix the focus issue.

Thanks!
 
I was an internal LIST user,
but since it was no longer going to be looked after,
I switched to LESS.

These is a version of LESS for Windows;
Ref: less-Windows

A good reference for LESS can be found at SS64.com.

I use Winget to install/keep updated, the LESS program.
Code: 
winget install jftuga.less

The only thing that I dis-like about LESS for Windows,
is that I cannot use the middle mouse button to scroll the text.

To prevent less from clearing the screen on exit,
you can start it with the option -X:
Code: 
less -X FILE

Joe
 
RobN said:
Here's some new information:
  • I am launching TCC.exe directly from a shortcut on my start bar, no command line arguments, and it's in its own terminal window (I believe it's a windows terminal window).
  • Use "list" on "updater.ini" in the TCMD folder.
  • Hit "F" to search for a term in here, like "AppDir". It jumps to that term, but further keypresses do not work (eg. "ESC" to exit, "N" for next find, etc)
  • The new infromation: The terminal window is losing focus. If I click back into the terminal window, then it's not frozen (eg. "ESC" and "N" work)
  • The find dialog box (where you type in the search term) is NOT present on the screen until I click back on the terminal window, and after I click on the terminal window it's partially off screen (straddling my monitors and off the top of the screen).
  • I run two 4k (3840x2160) monitors at 125% scale. I just tried 100% scale hoping that might explain the find box partially off screen, but it did not change the behavior.

Also "list" works in both TCC.exe and TCMD.exe, but only "TCC.exe" does it lose focus when you use "F" for find. In TCMD.exe it does not lose focus.

So I'd like to revise my report that this isn't a hang, but rather a change of focus issue. This is new behavior vs. old versions of TCC that I've used for years. Old versions keep the focus on the terminal window after you find.
Click to expand...

I think you will find similar issues with the [G] Goto Line dialog and the [O] Open dialog. LIST was designed for console windows, years before Microsoft started the Terminal project.

LIST uses the console window (a) to position the popup dialogs on the screen, and (b) to restore the focus when the dialog closes. Windows Terminal provides an unseen, ersatz "console window" which is useless for both.

If you would be interested in trying a plugin approach, I have a plugin designed to help with both issues. PopupFix Plugin
 
Charles Dye said:
I think you will find similar issues with the [G] Goto Line dialog and the [O] Open dialog. LIST was designed for console windows, years before Microsoft started the Terminal project.

LIST uses the console window (a) to position the popup dialogs on the screen, and (b) to restore the focus when the dialog closes. Windows Terminal provides an unseen, ersatz "console window" which is useless for both.
Click to expand...
To elaborate, because of what Charles mentioned, it might be that a message box like the one below is created BEHIND the WindowsTerminal window (or even off the desktop, depending on where the useless console window is) and LIST is waiting for you to dismiss the message box (which you can't do).

1723322717479.webp
 
What would be a really neat trick would be to somehow intercept GetConsoleWindow() and return the handle of the Windows Terminal window. Or the Console2 or ConEmu window, whatever. Only (a) I have no idea how to go about it, and (b) it would probably set off virus scanners from here to Adelaide.
 
Charles Dye said:
What would be a really neat trick would be to somehow intercept GetConsoleWindow() and return the handle of the Windows Terminal window. Or the Console2 or ConEmu window, whatever. Only (a) I have no idea how to go about it, and (b) it would probably set off virus scanners from here to Adelaide.
Click to expand...
You'd want to "hook" a Win32 API. Have you ever Googled "how hook Win32 API". I will momentarily. You could probably find out how to do it easily, though doing it might not be easy. As for (b), maybe, but you can always make an exception.
 
A reminder that @rconn has stated;
I have no plans to chase Windows Terminal compatibility.
IMO it's a slow, buggy, and extremely feature-limited substitute for TCMD.
Click to expand...

Ref: Windows Terminal ... Pop-up location

Thus, hooking a Win32 API for a solution sounds interesting.

Would it be possible to use SendMessage to send a message to the LIST screen/Windows Terminal, to return focus?

Joe
 
If I launch TCC.EXE via OpenConsole.exe;
Code: 
E:\Utils>"C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\Terminal\ServiceHub\os64\OpenConsole.exe" tcc.exe
...I cannot duplicate the problem with the LIST command.
Code: 
*list /n "%_ininame"

The _parent internal variable shows that I am running TCC from OpenConsole.exe;
Code: 
E:\Utils>echo %_parent
C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\Terminal\ServiceHub\os64\OpenConsole.exe

It is only if I run TCC.EXE from Windows Terminal that I can duplicate the problem with the LIST command;
Code: 
E:\Utils>echo %_parent
C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.20.11781.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe

The plugin solution suggested by @Charles Dye in post #9 does fix the problem with the LIST command in Windows Terminal.

Joe
 
OpenConsole.exe without Windows Terminal is pretty much the same thing as conhost.exe.
 
I've confirmed that when I use "conhost.exe tcc.exe" it works as expected: the window for "Search String Not Found" appears, I can hit "enter" for "okay" in that window, and focus returns to the conhost terminal.

When using Windows Terminal the "Search String Not Found" dialog is not on screen and and accepts no input, and it requires me mouse clicking back into the Windows Terminal window to continue working.

It appears this is a poor interaction between Windows Terminal (1.20.11781.0) and TCC (TCC 32.10.21 x64 Windows 11 [Version 10.0.22631.3880])? Is this something you'd add want to fix?

For now, I can use conhost instead of Windows Terminal, but based on this article I just read it seems like that I may be pinning myself to the past by doing so (great 5-part article btw: Windows Command-Line: Backgrounder )

Alternately I could attempt to use TCMD. I haven't done so yet because I rarely want tabs (I lay out multiple console windows across my screen and run jobs in each that I need to monitor the output on). Is there an option to avoid tabs and make the screen footprint smaller by removing the menu bar and tab bar? I want something lean as possible so I can fit more windows on screen. (Windows Terminal collapses all this in the title bar and has a screen-footprint that isn't much different from conhost).

Thanks.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate