mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 1,950
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,950
I've stumbled across a weird glitch in the vertical scrollbar for a dialog list control which seems to be affected by whether the number of items in the exceeds 65535 by a few/many.

When you try to drag the scroll focus downward, it will snap right back to a position near the top. Sometimes, if you hold the scroll focus in the middle for a long time, it will stay there when you let go of the mouse. But if you then grab the scroll focus again, the view immediately shifts to the top again, and the scroll square will bounce back up to the top again.

It's usually affected, but not always, by whether the number of items in the list exceeds 65535, and sometimes is affected by what's the total number of items loaded into the control the 1st time. I've even managed to start it with the glitch being gone at rows=65534, and then have it show up after manually adding fewer than a dozen additional rows.

The example re-creates a hash table and reloads the list control each time you click on 'create', but it's lightyears faster to load the dialog list using $hfind than to have a loop which adds them one at a time.

Code
dialog biglist {
  size -1 -1 200 200
  option dbu
  button "create (slow)",3,6 100 50 20
  list 6, 101 11 70 62
}
on *:DIALOG:biglist:sclick:3:{
  did -r $dname 6 | hfree -w test | var %i 1
  while (%i isnum 1-65534) { hadd -m1 test $+(item,%i) $+(data,%i) | inc %i }
  noop $hfind(test,*,0,w,did -a $dname 6 $1 )
}

Joined: Dec 2002
Posts: 5,231
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,231
Thanks for your bug report. This issue was probably first discussed around 20 years ago :-) This is a Windows limitation related to the WM_VSCROLL message for the scrollbar which can only handle a count of up to 65535. Although it's possible to get around it for a scrollbar control, there is, as far as I know, no way to get around it for a scrollbar that is part of a listbox. If anyone finds a way, let me know.

Joined: Sep 2003
Posts: 34
O
Ook Offline
Ameglian cow
Offline
Ameglian cow
O
Joined: Sep 2003
Posts: 34
This url shows how to do it in basic, but the method can be easily copied in c++

Millions of items

Joined: Dec 2002
Posts: 5,231
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,231
Thanks. This is the solution I mentioned that works for scrollbar controls but, unfortunately, does not work for scrollbars in listboxes. It half-works... while dragging the button, it will still show the wrong items in the listbox. I probably should have added a caveat in my above post: if anyone finds a way that they have tested and verified ;-)

Joined: Sep 2003
Posts: 34
O
Ook Offline
Ameglian cow
Offline
Ameglian cow
O
Joined: Sep 2003
Posts: 34
I've tested a c++ version of this code in a subclassed WC_LISTBOX with >64k items & it seems to work fine.
Dragging the thumb scrolls the items from first to last with no jumping about & all items appear correct, have i missed something ?

Joined: Dec 2002
Posts: 5,231
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,231
Okey dokey, please email me your C project for this and I will compile it and test it here.

Joined: Dec 2002
Posts: 5,231
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,231
Thanks for the code. It is similar to the code I was testing, apart from the VK_HOME/VK_END handling. When I test it out in your project, it works but it is still reproducing the same issue in my code. There is a lot of old subclassed code here, some of which already handles VM_VSCROLL, so my guess is that there is a conflict somewhere. Also, looking through the custom keyboard handling code for listboxes, I would have to place the VK_HOME/VK_END code somewhere in the existing sequence of key press handling and it's not entirely clear where that would work best without interfering with existing code and causing other issues. Right. I am going to have to whittle this down.

Update: Okay. Managed to get it to work by re-arranging some code. I am not going to implement the VK_HOME/VK_END fix. It requires more code changes to keyboard handling than I'd like and since its purpose is to fix listbox handling of VK_HOME/VK_END with two million+ listbox items, I am going to go out on a limb and say this is not going to be a priority for 99.99% of users. Also note: this fix will only apply to custom dialog listboxes/comboboxes and window listboxes such as in @window, channel nickname list, URLS list, and so on. It will not apply to any other listboxes since this would require subclassing every listbox in every window/dialog throughout mIRC. If it looks like this fix causes other issues (it is basically intercepting WM_VSCROLL, blocking it, and sending two other windows messages in its place, which could in turn trigger other messages, events, etc. which could cause backward-compatibility issues with scripts/DLLs), I will revert this change.

Update: I've decided to apply this fix only to custom dialog listboxes/comboboxes and @window listboxes. It will not apply to any other windows.

Last edited by Khaled; 02/02/22 01:09 PM.

Link Copied to Clipboard