Strange behavior of the Slider when using the mouse wheel

General JUCE discussion
1

When using the mouse wheel in strictly one direction, it is possible to move a Slider in BOTH directions!
When moving slowly or quickly, the slider moves in the expected direction. But with the right speed somewhere in between, the slider moves in the opposite direction.

I tried to figure this out by myself, but strangely Slider::Pimpl::mouseWheelMove was never hit in XCode 5. I outcommented

if (e.eventTime != lastMouseWheelTime)

as well as

(wheel.isReversed ? -1.0f : 1.0f)

but neighter changed the situation.

This happens in my own application as well as in the JUCE demo and even in Tracktion.

I tried it with a Logitech mouse as well as with the Trackpad of my Macbook under OSX 10.9.4.

2

Huh? Never seen this myself! It sounds like you're just drifting diagonally with the trackpad..

3

No, sadly not. It also happens with an actual (1-axis) wheel on a real mouse.

Please try it with the Demo yourself. Scroll until the max or min of the slider is reached. Then continue with different scrolling speeds. The slider moves to the other direction.

And no, no custom modifications (I git stashed) and the latest Juce.

 

Edit: The issue on the real mouse happens only when the scroll wheel stopps. Sometimes it communicates a delta value into the other direction. So this is a hardware problem.

4

You were right, the reason is some slight simultaneous horizontal scrolling.

I was confused because it did not happen on horizontal scrolling - even thought there were also some deltaY !=0 . The reason is this line in Slider::Pimpl::mouseWheelMove:

const double delta = getMouseWheelDelta (value, (wheel.deltaX != 0 ? -wheel.deltaX : wheel.deltaY) * (wheel.isReversed ? -1.0f : 1.0f));

May I suggest to change it to:

const double delta = getMouseWheelDelta (value, (std::abs (wheel.deltaX) > std::abs (wheel.deltaY) ? -wheel.deltaX : wheel.deltaY) * (wheel.isReversed ? -1.0f : 1.0f));

This way it would be robust to slight offset scrolling in either x or y.

 

BTW: Is there a reason for choosing float literals at the end of that line? Would't double literals be better suited when assigning to a double?

5

Yes, good thinking, I'll take a look at that!

Sure, it could use 1.0 instead of 1.0f, but since deltaX/Y are floats it won't make any significant difference to the value, it just changes the stage at which the float->double conversion happens.