MouseDrag called on MouseDown


#1

Hi,

I’ve just updated from JUCE v3.2.0 to v4.2.3

It seems like there’s a behaviour change where Component::mouseDrag is now being called on mouse down. Currently I’ve only tested this on OSX 10.11.5.

Looking through the call stack it seems that the mouseDown callback in juce_mac_NSViewComponentPeer.mm internally results in a mouseDrag event being triggered.

Is this an intentional change?

I’ve never considered that a drag event could be called on mouse down event before and only noticed because it resulted in a bug. Should I expect this behaviour from now on?

Thanks,
Joe


#2

Interesting that when I step through the code, I can’t reproduce the same behaviour.

From juce_MouseInputSource.cpp::273

                if (isDragging())
                {
                    registerMouseDrag (newScreenPos);
                    sendMouseDrag (*current, newScreenPos + unboundedMouseOffset, time);

                    if (isUnboundedMouseModeOn)
                        handleUnboundedDrag (*current);
                }

Could it be that while this check is being done that the mouse button to trigger to the click is still held down. Which would suggest why I couldn’t reproduce it when I stepped through.

Any thoughts?


#3

If a drag is sent after the mouseDown and before a mouseUp then there’s nothing wrong.

The only bug I’d consider looking at would be if the callbacks are sent out-of-order.


#4

So the order of mouseDown, mouseDrag, mouseUp is still correct. Thanks for the info!


#5

For anyone reading this topic, this other one may also be relevant: On mac osx mouseDrag gets called on mouseDown


#6

On OSX, I find that when mouseDrag is triggered by a 3 finger gesture, it is usually preceded by a mouseDown, but not always. Is this intentional?


#7

It should be impossible for the MouseInputSource to dispatch a drag without having sent a mouse-down event… If you can find a code-path that lets that happen, let us know!


#9

Ok, this is not a bug. Here’s the event sequence:

  1. [user places three-finger touch]
  2. mouseDown
  3. mouseDrag
  4. [user removes three-finger touch from track pad, for < about 1 second]
  5. [user replaces three-finger touch]
  6. mouseDrag
  7. mouseUp

So, three-finger touch events that are not “physically” continuous may be regarded as “logically” continuous by JUCE (or the OS). I’m sure this is intended behavior, but perhaps good to know about.