Mouse wheel button and Drag&Drop

General JUCE discussion
1

Hi guys,

 

how can I prevent the mouse wheel button from triggering drag&drop. Normally the left

mouse button is used for that but the mouse wheel button also does it!

The problem is that in Cubase the mouse wheel (pressed) can be used to scroll the time line but

if you move the mouse (while mouse button is pressed) over around a drag&drop source component,

then it can also trigger drag&drop by mistake.

 

Thanks,

Joerg

2

No idea?

3

I don't understand, sorry.. You mean you begin dragging inside cubase's window, then move out over your plugin's UI? If so, I don't see how it could get the events at all, as they should still be getting sent to the window that got the original mouse-down..?

4

Yep, that is what I do and it actually only happens in Cubase. Reaper is fine for example

So I think Cubase does strange things here (as usual :-)) and I thought I could

prevent Cubase from doing soif I somehow eat the mousewheel button down message.

 

Joerg

5

Can't think of an easy fix to suggest.. I can't change the way that the juce window handling responds to the mouse-wheel button, because that might break other people's code. You might be able to add a hack to check for it yourself in the win32 stuff, I guess.

6

Okay, understand. Don't you think it would be easier to implement my own drag&drop mimic instead

of hacking the framework?

 

7

Quite possibly.

8

It seems to be a focus issue.

The following hack in juce_win32_Windowing.cpp worked for me and seems not to have negative impact even

if you try to drag&drop something from outside the app. Tested with JuceDemo.

void doMouseMove (Point<int> position)
{
    //This is to avoid triggering of drag&drop when
    //dragging the mouse over a component from outside
    if (! isFocused())
        return;
        
    if (! isMouseOver)
        {
            isMouseOver = true;
            ModifierKeys::getCurrentModifiersRealtime(); // (This avoids a rare stuck-button problem when focus is lost unexpectedly)
            updateKeyModifiers();

            TRACKMOUSEEVENT tme;
            tme.cbSize = sizeof (tme);
            tme.dwFlags = TME_LEAVE;
            tme.hwndTrack = hwnd;
            tme.dwHoverTime = 0;

            if (! TrackMouseEvent (&tme))
                jassertfalse;

            Desktop::getInstance().getMainMouseSource().forceMouseCursorUpdate();
        }
        else if (! isDragging)
        {
            if (! contains (position, false))
                return;
        }

        static uint32 lastMouseTime = 0;
        static int minTimeBetweenMouses = getMinTimeBetweenMouseMoves();
        const uint32 now = Time::getMillisecondCounter();

        if (now >= lastMouseTime + minTimeBetweenMouses)
        {
            lastMouseTime = now;
            doMouseEvent (position);
        }     
}

 

Would this destroy other users code?

9

No, I think you'd often want unfocused windows to get mouse-move events, so there are many places where that change would cause terrible problems. Perhaps ignoring events when the button is already down in another window might make sense, but definitely not what you're suggesting there..

10

Perhaps ignoring events when the button is already down in another window might make sense

Well, that is what I actually wanted to achieve but didn't really know where to put in the framework. 

You know all the dependencies much more than me and now that you are thinking of a way of doing this,

where would be the best place to filter those messages?

 

Much appreciated!

Joerg