Mouse Wheel interaction

Apr 7, 2011 at 11:42 PM

Specifically more for the DateTimeUpDown and NumericUpDown, the mouse wheel should only work if and only if is has focus. 
Like for a ComboBox, when it has focus the mouse wheel will work if the window has focus and the object has focus but the mouse wheel will not work if it doesn't have focus. The current way how it works is that if the mouse is over the object, it uses the mouse wheel actions regardless of having focus.

Apr 8, 2011 at 1:53 AM

This behavior has been corrected in the current source code.

Apr 11, 2011 at 3:50 AM
PeterLink4 wrote:

The current way how it works is that if the mouse is over the object, it uses the mouse wheel actions regardless of having focus.

Oddly enough that is the behavior that I prefer. In case where you might be modifying multiple UpDown's simultaneously, the overhead of having to 'click in' to the UpDown to give it focus can be rather annoying as opposed to simply moving the mouse over.

Apr 11, 2011 at 3:54 AM

Maybe the addition of a new property called MouseWheelActiveOnFocus would be helpful.  Submit a request and let's see how many votes it gets.

Apr 18, 2011 at 4:50 PM

This feature has been implemented and is available in the latest source code download.

Apr 20, 2011 at 8:14 PM

I would like the mousewheel scrolling to work when a control has focus but the mouse is not hovering over it. I understand why the mouse has to hover over it, because you would still want the wheel to scroll the parent window without having to lose focus on the control but i would use this in UIs where the window will never have a scroll bar.

Maybe add an enum property to determine if mousewheel should work in the cases:

  • mouse must hover over control and control must have focus
  • mouse must hover over control but focus does not matter
  • mouse position does not matter but control must have focus
Apr 21, 2011 at 1:26 PM

There are a couple of issue with that type of feature.

  1. I cannot capture the mouse wheel events when the mouse is not over the control. (at least easily and without using COM calls)
  2. This could cause major confusion to the user who may be trying to use the mouse wheel on another up/down control, but hasn't moved focus and therefore is manipulating a different control without realizing it. 

Thank you for the suggestion though.

 

 

 

Apr 22, 2011 at 2:57 AM
Edited Apr 22, 2011 at 4:52 AM

Why would that cause "major confusion" for the user? That's exactly how I expected it to work when I first tried the control. I was wondering why I expected it to work that way so I tried out the NumericUpDown in WIndows Forms and that's exactly how it works. So, if anything the way your NumericUpDown controls work now would cause major confusion for the user that has been using Windows Forms applications for years when they try to spin through values only to find out that it doesn't even work unless they position their mouse in a specific area.

But if you can't do it anyway I guess it doesn't even matter.

Apr 22, 2011 at 2:32 PM

You expected it to work like WinForms because you were trained by the WinForms control behavior.  I do not agree with that behavior and just because that is how is works in WinForms doesn't mean that is how it should work in general.  We all have our opinions on how things should work and those opinions will help shape this toolkit into a great toolset for WPF developers.  I appreciate the feedback and keep it coming, but in this particular case I will be keeping the behavior as is.