Hi, I’m seeing issues with velocity drags on vertical sliders either jumping or not moving at all in one direction. The WidgetsDemo app demonstrates the problem on vertical sliders when holding the ctrl/command modifier.
Tested on v5.3.1
Thanks.
I was hoping for a little more help here by now but I guess sliders are too boring to investigate!
Looking at the jumping issue this seems to happen due to MouseInputSource::handleUnboundedDrag(…) resetting the screen position to the components centre when traversing beyond the components bounds.
I’m not sure how to best handle this case?
Surprising that I’m the only one hitting this considering the demo widget app exhibits the problem on both Mac OS and Windows.
Mike.
Sorry, can you be a bit more specific?
Everything seems to be working fine for us on the latest JUCE. On macOS, exactly which keys are you holding down when?
Ctrl clicking the slider will bring up a popup menu to select velocity mode. Dragging the slider with the command modifier will invert what ever velocity mode is currently selected (so the default will be that it uses velocity mode). Option dragging the slider will snap it to a specific value (like “50 units”). As long as the option key is still down, the slider won’t move after snapping but that’s expected behaviour.
Hi Fabian,
Sorry I should have just said holding ctrl down whilst dragging or selecting velocity mode from the popup menu. The issue is sudden large jumps in the slider position when trying to drag the slider at a consistent velocity. For some reason the issue is easier to reproduce on my Windows desktop PC than my macbook (probably related to screen scaling and mouse sensitivity etc.).
The issue occurs when MouseInputSource::handleUnboundedDrag(…) resets the mouse position to the centre of the component whilst dragging. If you put some debug trace in to slider::handleVelocityDrag(…) and print out the mouseDiff you will see large unexpected jumps just after the mouse position resets.
This may take a few goes to trigger with smooth consistent mouse control but it’s easy to trigger when you have the knack.
Thanks for investigating,
Mike.
I’ve been looking at this bug for most of the day but can’t seem to find a good fix for it. As you say, the problem occurs if the mouse cursor hits the edge of the screen. To still continue dragging, JUCE sets the cursor position to the middle of the component. JUCE will then apply a correction to any subsequent mouse move messages to account for the jump in cursor position, so that for JUCE components it looks like the mouse is moving even further up (beyond the bounds of the screen).
The problem occurs because even after setting the cursor position to the middle of the component, win32 will still send a few mouse move messages located at the old position before SetCursorPos was invoked - and the correction is then applied twice etc. I’ve tried flushing any mouse move events that are queued just after re-positioning the cursor but this does not seem to help.
Googling the problem brings up this win32 bug report:
Does anybody have any suggestions how this one could be fixed?
1 Like
bump, this is still a thing.