Welcome!

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

SignUp Now!

LIST utility interferes with Windows mouse input

Aug
197
5
I don't use the LIST utility much, so I haven't previously reported this issue that I've seen for quite some time. But now I have some use cases involving it, so I thought I'd post about this problem separately. Any time I use the LIST utility to display the contents of a file, display the results from STDIN, or any other purpose really, it seems to interfere with Windows mouse input. While the LIST utility is running in TCC--note well this problem does not happen when using it in TakeCommand, only when using it in TCC (whether in the Windows Terminal or in the console host I should add)--my mouse cursor is slow to move and wanders as if the USB input stream is somehow being messed with or perhaps the LIST utility is utilizing the system so heavily (the task list performance tab doesn't show any weird CPU spike or anything). It makes it very difficult to use the computer while it's running. Is this a known issue? Is there perhaps any workaround or settings I can try to fix it? Nothing I've found so far helps. Thanks!
 
Try this: OPTION, select the Startup tab, and turn off the option "MouseWheel support in LIST".
 
Without that option, the scroll wheel doesn't work as you would expect in LIST. But that's really not a big deal; if you turn the scroll wheel, just turn it back in the opposite direction. A momentary annoyance.
 
If you have that option set, TCC installs a low-level mouse hook so LIST can support the mouse wheel. There are a few systems / mouse drivers where this causes an issue (for as-yet unknown reasons).

Note that LIST has been deprecated for years; it was replaced by VIEW.
Helpful explanation. Thanks also for mentioning view. When I'm in a terminal, I prefer to stay in the terminal. View is nicer in various ways, but it takes my focus away from the terminal. I also find the "/W" switch doesn't work very well since the Windows Terminal oh so "helpfully" took over all my terminals insofar as it causes view to open in a tiny window at the upper-left of my primary monitor rather than over the top of my TCC session. It still works fine if I'm using TCC in a console window, not Windows Terminal, but that's a whole 'nother thing.
 
I also find the "/W" switch doesn't work very well since the Windows Terminal oh so "helpfully" took over all my terminals insofar as it causes view to open in a tiny window at the upper-left of my primary monitor rather than over the top of my TCC session. It still works fine if I'm using TCC in a console window, not Windows Terminal, but that's a whole 'nother thing.

You're not running the latest build, are you?
 
You're not running the latest build, are you?
I was running this:

TCC 34.00.15 x64 Windows 11 [Version 10.0.26100.3194]
TCC Build 15 Windows 11 Build 26100

After updating to the latest, I see that issue I mentioned with the view command and the "/w" switch is fixed when run from TCC inside the Windows Terminal. Thanks for that!
 
After updating to the latest, I see that issue I mentioned with the view command and the "/w" switch is fixed when run from TCC inside the Windows Terminal. Thanks for that!

Rex has been making a ton of Windows Terminal-related fixes recently. I suspect that most of them have never even been mentioned, in the documentation or here in the forum.
 
Rex has been making a ton of Windows Terminal-related fixes recently. I suspect that most of them have never even been mentioned, in the documentation or here in the forum.
And I am happy to say that I can run Neovim again in TakeCommand itself! It's not as "pretty" as in TCC because it seems like there's some kind of limited font/color support, but it's actually usable in TakeCommand again like it and Vim used to be! What a pleasant surprise!
 
Back
Top