Welcome!

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

SignUp Now!

Mouse wheel scrolling in TCC. What should we expect?

Nov
339
7
I'm a heavy user of the select command. Last weekend, I was selecting some files when someone else tried to scroll up the file list using the mouse wheel... and it didn't work: instead, the entire thing went down, showing part of the screen buffer (as it occurs normally when on the command prompt).

I was surprised - I would have expected the screen buffer to be temporarily disabled during the select command.

May this be an oversight or it's WAD?

Thanks.



This was all using TCC/LE 13 - I haven't taken the time yet to try this on other versions or the full TCC.
 
WAD - the only place that TCC supports mouse scrolling is in the LIST command. It is an *extremely* painful process to do this in a console window, both in code & cpu usage (it requires installing low-level mouse hooks and monitoring all messages), and is fraught with peril if anything goes wrong. @SELECT hasn't been considered important enough to take the hit.
 
I had long suspected that mouse wheel scrolling might be supported in LIST and now that's been confirmed. I say suspected because I've never once seen it work on any system where I've tried it.

I'm currently running TCC 12.01.44 under XP SP3 but I've always seen the exact same behavior in older versions of TCC. It seems to make no difference whether I'm using Microsoft's IntelliPoint drivers or Logitech's SetPoint drivers. I admit that I've never tried it just with Windows' built-in mouse drivers, since I literally always install either the IntelliPoint or SetPoint software very early on in every system setup. At any rate, the specific behavior that I always see is that when any file is being LISTed, the moment I roll the wheel in either direction the session becomes totally unresponsive and eventually begins beeping like mad. The entire system becomes sluggish while this is occurring. There's rarely any way to break out of it other than to kill TCC in Task Manager (or something equivalent). Occasionally, I can click the close button on the window but more often than not I have to kill the process itself.

LIST is the one place in TCC in which I would dearly love to be able to scroll with the wheel. If anyone else has also experienced this and beaten it or has any suggestions of things to try to get this to work, I'd love to hear your ideas.

(Apologies if this reply constitutes thread jacking, which wasn't my intent.)
 
Heh, I was worried for a second there that I had stupidly overlooked some patently obvious fix, but that option is indeed enabled.

Having never once seen the wheel work in LIST, my assumption is that I should be able to use it to scroll to any point in the file(s). In case it bears mentioning, my various TCC shortcuts are all configured to have the screen buffer and window sizes be the same. (Yeah, yeah, I know this is inefficient but it prevents vertical scroll bars from appearing, which I very much dislike seeing in console windows. To each his own.) However, if I temporarily increase the screen buffer size to be larger than the window size (or open a TCC tab in TCMD), using the wheel causes the entire screen buffer to scroll, which I assume is not the expected behavior while in LIST.

If my experiences are unique, then just about the only other thing I can think of to try at the moment would be to start with a totally clean Windows installation and figure out at which point in my setup process that LIST/wheel functionality goes bad. Sadly, that's not a viable option at present. For now, I'll stick with the learned behavior of keeping my hands as far away from the mouse as possible while in LIST.
 
I haven't heard of anybody having problems with the mouse wheel in TCMD / TCC for the last several versions. I just verified it on 5 machines here; it worked in all cases (2 Microsoft mice, 1 Logitech, 2 trackpads).

In the past, when there were problems it was always due to an outdated mouse driver. Assuming you've checked for updates, I would think the likeliest cause would be another app also trying to hook the low-level mouse messages.

In any event, it may not be worth the time and trouble for you to track it down, given that LIST is obsolete (replaced by VIEW).
 
Rex,

Just as a rather-humorous aside (I think! :) ) I find the "List" command to be far better than the "View" command is for me because my recollection from my limited experience(s) with the "View" command when I tried out V13 were that it was almost unusable (for me) because it was basically a GUI app, and I just don't do GUI apps! (So please don't ever take "List" command away; I find it to actually be one of the best "features" of TCC, and it is one of the things I brag about the most - which I did just today!!!)

- Dan
 
I use both. Each has its own strengths. VIEW opens a separate, independent window -- which is either good or bad, depending on what I'm doing. VIEW also has better support for different character sets and encodings.
 
If I want to open a separate window, I use my text editor. With List, I can look at a file in the same place as the TC/TCC window, so I don't have to reposition it or move it out of the way, and it is quick and simple to use. (And I can't make View stay over the TC tab window because I have focus-follows-mouse turned on.)
 

Similar threads

Back
Top