Scroll wheel not working with 65536 files

[Zom-B]

When a directory contains 65536 files or more, the scroll wheel suddenly stops working.

This might be related to a fixed bug in which the selection wrapped modulo 65536 in version 6.53 and earlier.

[ghisler(Author)]

Unfortunately I couldn't find any hint in my code from where such a limitation could come.
Can you determine whether TC itself or the mouse driver scrolls the list, please?

Just add the line
IgnoreWheel=1

to your wincmd.ini section [Configuration].

[rowkajjh2]

I believe this is because the underlying windows-function (GetScrollPos() etc.) uses UINT (or something like that) and is therefor limited to 65536 positions.

[CoolWater]

I believe this is because the underlying windows-function (GetScrollPos() etc.) uses UINT (or something like that) and is therefor limited to 65536 positions.

GetScrollPos() etc. use 32 bit int. So 65536 cannot be the limit...

[Zom-B]

Unfortunately I couldn't find any hint in my code from where such a limitation could come.
Can you determine whether TC itself or the mouse driver scrolls the list, please?

Just add the line
IgnoreWheel=1

to your wincmd.ini section [Configuration].

With IgnoreWheel=1 it also refuses to scroll in the big directories.
Just to be sure, I tried IgnoreWheel=0. Same result.

[Flint]

ghisler(Author)
Some additions: this is reproduced in Full view, but is not reproduced in Brief view. Also, maybe, it needs using Branch mode.

[SanskritFritz]

With IgnoreWheel=1 it also refuses to scroll in the big directories.
Just to be sure, I tried IgnoreWheel=0. Same result.

this is reproduced in Full view, but is not reproduced in Brief view

Confirmed both.

[Clo]

2ghisler(Author)

Good morning,

• Is it not a limitation of Windows about the number of files per folder ?
- I remember (vaguely…) to have read something like this ages ago, with exactly that value…

• Maybe M$ forgot to remove¦improve this in the newer Windows (2k¦XP…) ?

 VG
Claude
Clo

[SanskritFritz]

I believe this is because the underlying windows-function (GetScrollPos() etc.) uses UINT (or something like that) and is therefor limited to 65536 positions.

I also think that it is a limitation of the listbox control. Like, isnt lParam in the WM_MOUSEWHEEL message simply an UINT, that is 16 bit long?

[tcrobbi]

Its the WM_xSCROLL-Messages. There are 16bit. To get 32bit values one have to use Get/SetScrollInfo. Perhaps a limitation of delphi 2 too?

[now]

Last time I read the Windows API, a normal listbox can't hold more than 65535 (or was it 65536?) entries.

[ghisler(Author)]

With IgnoreWheel=1 it also refuses to scroll in the big directories.
Just to be sure, I tried IgnoreWheel=0. Same result.

If it fails with IgnoreWheel=1, then TC doesn't even react to the wheel messages (just to listbox scroll messages). Therefore the bug is somewhere in Windows...

[kAtremer]

Same behaviour in `Synchronize dirs` dialog, when number of files goes above ~65535 (not exactly, somewhat lower than that).