Modifier key behaviour wrong in mouseDrag

Windows
1

I just noticed something perculiar. I wrote components where holding shift slows down the action, sensitive drag. But if I stopped holding shift during the drag it did not switch back to normal drag before mouseUp. Likewise if I didn’t start the drag with shift, starting to hold it during the drag would not initiate sensitive drag. It only happens in the DAW (I was testing with the latest version of Bitwig) and not in standalone. Furthermore it only happens with the mouse that I added to my laptop via USB and not with the builtin trackpad. I can’t test it right now but I can’t recall this happening on my main computer at all, where I only have this mouse.

Here’s my theory: Maybe JUCE interprets a change in modifier keys during a drag wrong for every mouse that is not the main mouse of the system when the host is not just the plugin itself. Hopefully it’s not just Bitwig making it impossible to implement basic UX again. Would be cool if this was fixed, because it can be confusing to be stuck on a certain kind of drag all the way through.

Edit: Ok, it does not happen in Reaper. So apparently it’s a Bitwig thing. But still worth investigating. Maybe there could be made a hack around the issue

2

I’ve noticed this behaviour in windows 10 in reaper, but it’s very inconsistent. Happens maybe 1 in 10 times.

3

I had this problem a while ago, but I thought it was solved until yesterday

4

accessing the key state via juce::ComponentPeer::getCurrentModifiersRealtime().isShiftDown(); works. There is something going on in the cached version which propagates to mouse events.

2 Likes
5

solved! :slight_smile:

6

legendary post