We are using the UltraToolbarsManager object to create a ribbon. The tabs on the ribbon can be scrolled with the mouse wheel. We haved noticed that using a Microsoft 5-button mouse the tabs will scroll left and right as appropriate. Mouse wheel up scrolls the selected tab right, mouse wheel down scrolls the selected tab left. We have also confirmed these are the tabs reported in the BeforeRibbonTabSelected and AfterRibbonTabSelected events.
However, when using an HP 3-button mouse, the selected tab will only scroll to the left. This likewise has been confirmed in the BeforeRibbonTabSelected and AfterRibbonTabSelected events.
Both mice are using the same Microsoft driver: 6.1.7600.16385 dated 21 June 2006.
This behavior is not observed on any other ribbon based UI which supports this functonality on the same computer (e.g. MS Office products, WinZip). Is this a known issue with the Infragistics component, and if so is there a known workaround?
Hi Jason,
The Ribbon doesn't have any awareness of the hardware. It's just handling Windows messages. So the amount scrolled by the mouse wheel is determined by system settings and mouse drive settings. Most mouse drivers allow you to set the delta or the number of lines to scroll when using the mouse wheel. I've never seen a mouse driver that lets you specify different values for up and down, though. Usually, it's just one value for both directions. So it's very strange that it works one way and not the other.
Jason Hart said:Mouse wheel up scrolls the selected tab right, mouse wheel down scrolls the selected tab left.
This probably isn't important, but I tried this out on my machine and I get the opposite result. Spinning the mouse wheel up selects the tab to the left and spinning the mouse wheel down selects right. So it would be very odd if your machine worked in the opposite direction. Are you sure you didn't get this backward?
Are you testing both mice on the same machine? Or are these two different machines?
I would be interested to see what the Delta is for the MouseWheel on your machine (or machines). I have attached a small sample project here for testing. It's very simple, it's just a Form where I hooked the MouseWheel event and output the Delta to the Output window. If you could run this sample and just spin the mouse wheel up and down and see what numbers you get with each of the mice you listed here, that might help us determine what's going on here.
WindowsFormsApplication65.zip
Jason Hart said:Is this a known issue with the Infragistics component, and if so is there a known workaround?
No, it's not an issue we are specifically aware of... but I took a look at the source code for the ribbon tab scrolling and it does seem like there are some holes here. Unfortunately, the tab is using a message filter and not handling the MouseWheel event, so I can't see any way to work around it on your end. What version of the controls are you using? We won't be able to reproduce the issue here since we don't have the same hardware, but I'm pretty sure I see ways in which this code could be improved so that it will probably fix the problem you are experiencing.
Hi Mike,
We are on version 18.1.20181.237.
I have reconfirmed the directions. Scrolling the mouse up moves the selected tab to the right, scrolling the mouse down moves the selected tab left.
Both mice are plugged in to the same machine, but I am RPCing to a virtual machine. They have seen it only scrolling left on an actual machine.
The results from your program do reveal a difference:
MS 5-Button Delta- Up: 28 (and multiples of 28)- Down: -28 (and multiples of -28)
HP 3-Button Delta- Up: 120 (and multiples of 120)- Down: -120 (and multiples of -120)
Thanks,
Jason
This just gets weirder and weirder.
So the 5 button mouse, which works correctly, is using a Delta of 28, and the one that doesn't work is using 120? Once again, this is backward. I would've expected it to go the other way. 120 is the standard and that's what the Ribbon is using as a value for 1 tab scrolled.
In any case, as I mentioned, I wrote this up for the developers to review so it should be fixed in the net SR. We really shouldn't be relying on the delta, anyway, except to determine the direction. So that's a bug.