Program fails to respond to rapid mousewheel events

Rin Rin 10 years ago updated by Alex Jenter 10 years ago 8

When scrolling the notes list, mousewheel events that occur above a certain rate (such as those sent by many Logitech mice with "frictionless" scroll wheels) appear to be thrown out by the program wholesale.  They aren't even capped to a certain number per second—it is possible for the program to fail to register a single event from the start of the movement until the wheel slows down enough to begin to register.

This is frustrating, and damaging to the user experience for those it affects.

notes-list main-window mouse


Released in V2.5

Hi Rin Rin,

thanks for the report! 

Could you please tell in more detail how to reproduce the problem? 

It could also help to know which mouse you have, your OS version, and what are your system mouse wheel settings?



Mouse: Logitech G700

OS: Windows 8 (Have not updated to 8.1 yet)

CPU: Intel i5-3550

System Mouse Wheel Settings: Unchanged (set to 3 lines per tick)

Vendor Settings: None (Logitech setpoint not installed)

Having done some additional testing of my own with a small C++ program, I can tell you that the mouse is sending events at the following rates:

Delta: +/-120 on all events

Click Mode: 30ms (33 events per second)

Casual 'Frictionless' scrolling: 20ms (50 events per second)

Solid 'Frictionless' flick: ~6.66ms (150 events per second)

Maximum observed: 4ms (250 events per second)

I also threw together an autohotkey script to help reproduce the effect.  I was not able to reproduce the complete event lockdown that I experience with the mouse, but this may be due to the scripting language used not reaching the same speeds.

The compiled or plaintext versions of the script can be found below:

Windows Binary: CintaNotes_ScrollingIssueReproduction.exe (standalone)

AHK Script: CintaNotes_ScrollingIssueReproduction.ahk (Requires Autohotkey)

Usage: Running the script should pop up a window with several controls.  The left side provides the ability to set the delay between events including type-in entry as well as a button to ramp the value up and down over time.  The script should automatically recognize CintaNotes by the class CintaNotes.MainFrame and sends messages to the control Cinta.NotesList1 as reported by a tool provided by Autohotkey.

It bears noting that the script above sends a scroll message (0x115) directly to the program.  Wheel events (0x20A) were tested with similar results, but required mouse coordinates to aim them properly, so are not included in the script.

Though full lockout was not reproduced, clear degradation is observed on my system, with CintaNotes scrolling perhaps ten lines over the course of 50 events at the highest speeds (which, as mentioned previously, do not reach the labeled speeds due to the limitations of the scripting language used).

I understand that the sheer number of events mentioned seems rather unreasonable—especially considering the above script can't even fire the events off fast enough to fully reproduce the error—but I don't believe this is a straight-up performance issue since my workaround is to intercept the mousewheel events and send up/down arrow events instead.  Scrolling as a result of the arrow keys selecting notes is plenty fast, though it's irregular since it depends on the size of the notes in the view (I allow them to be quite large.)

Anyway, good luck with the issue; I hope it's fixable.

Wow, thanks for such professional and detailed info! (I almost feel like I just need to show you the 'OnMouseWheel' function source code and you'll spot the bug! :) Really glad to have such people use CN.

Will run some tests and get back as soon as I can.

Could you please try this version:


I'm glad my previous comment was helpful for you.

Unfortunately, though, the version you linked seems mostly similar.  In fact, in practice I would say that it actually feels a little slower overall, though the scrolling is more regular, at least.

Thanks. Could you please try it one more time?


That one works great!

Cool! You can expect this fix to appear in the next program update. Thanks for your outstanding help!

Released in V2.5