"The delta was set to 120 to allow Microsoft or other vendors to build finer-resolution wheels in the future, including perhaps a freely-rotating wheel with no notches. The expectation is that such a device would send more messages per rotation, but with a smaller value in each message. To support this possibility, you should either add the incoming delta values until WHEEL_DELTA is reached (so for a delta-rotation you get the same response), or scroll partial lines in response to the more frequent messages. You could also choose your scroll granularity and accumulate deltas until it is reached."
Unfortunately, many people seem to have glossed over that, and even the rest of the content on the page.
Some of the problems I have faced when using a smooth Microsoft mouse wheel:
- Applications scrolling in the same direction whichever way you turn the wheel (unless you turn it exceptionally fast). I would guess the bugged code in question would be something like:
scroll_direction = delta1 >= WHEEL_DELTA ? UP : DOWN
Microsoft's Performance Analyzer fits this category.. - Applications not scrolling at all unless you turn the wheel really fast. The problem in this case would be the application ignoring |delta1| values less than WHEEL_DELTA. The new PerfectDisk 10 fits this one.
- Applications scrolling erratically/"too much". The problem in this case is that they only check the sign of the delta1 value, and ignore the magnitude.
- Applications lacking common sense with mouse wheel scrolling. For example, on its rotating main menu Windows Media Center generally scrolls several entries at a time on when turning my mouse wheel.
- Not so much a bug but a nuisance nonetheless: applications accumulating delta1s until |delta1| >= WHEEL_DELTA is reached, when they could in fact have scrolled in smaller increments earlier. This affects many of the lists in the shell on Windows Vista, though I noticed many of those have been changed in Windows 7 beta.
5 comments:
Maybe the following MSDN wording is causing the problem:
"The high-order word indicates the distance the wheel is rotated, expressed in multiples or divisions of WHEEL_DELTA, which is 120"
This certainly suggests that the high-order word would be a multiple of WHEEL_DELTA, no?
I agree that doesn't help, but they should read the rest of the article. In particular the sentence starting with "To support this possibility..." does state that you should handle values that aren't a multiple of WHEEL_DELTA.
But yes, it should be clearer throughout the whole article. A bit more reading, care and testing, wouldn't go astray through.
I have the opposite issue -- I have a free-spinning Logitech MX Revolution, which not only spins freely, but for an extended period of time (and is wonderful, I'll never go back to clicky, fwit).
In programming, I only get the 120 unit jumps. Hence I would love to get the smaller jumps so I could have a finer level of control in my particular 3D app I'm writing (rotating objects.)
I can't seem to find a setting in the normal mouse nor Logitech control panels to alter this.
According to:
MOUSEINPUT Structure
http://msdn.microsoft.com/en-us/library/ms646273(v=vs.85).aspx
"One wheel click is defined as WHEEL_DELTA, which is 120."
Clicks. Hey, my wheel clicks. My wheel rotates. Independently! Orthoganally!
That page doesn't even mention high and low order usages regarding the mousedata argument.
The only thing that would make sense to me is different roles for the high and low order words of mousedata. Do they outsource the documentation prep to $#%&!?
I'm more confused than ever.
It's all designed by committee.
Agreed. Most windows apps are very bad in this regard.
Thankfully, Mac OS X is better in this regard, which is hugely thanks to its awesome trackpad that allows very fine-grained two-finger scrolling.
Post a Comment