Mouse constraints


#1

Something odd is happening here, and I’d appreciate any help anyone can offer.

I’m trying to lock the mouse cursor to a single position while the shift key is help down. Basically when drawing contours, I want a quick way for my users to be able to temporarily let go of the mouse, either to move it, rest their arm, or whatever.

The problem:

currently what I’m doing is overriding modifierKeysChanged to call Desktop::getMousePosition()

and in my mouseMove, and mouseDrag, overrides, I’m simply checking for the shift key, and if is down, calling Desktop::setMousePosition() with the x and y I got in modifierKeysChanged.

When I test this, I can see the cursor fighting back a little, as movement is extremely juddery, but I can still move the pointer around the screen.

Calling Desktop::getMousePosition() straight after calling setMousePosition shows that the values for x and y match the seed values. On screen the cursor is clearly moving though.

So, is there a better way of doing this?


#2

right, well I worked out more or less why it wasn’t working.

modifierKeysChanged() is getting called for every mouse move, not just for changes in mod key state, which was what I was naively assuming. That meant I was overwriting my seed co-ords each time the mouse moved. I thought that was the case earlier, but a stupid bug in my logging code sent me totally down the wrong path.

However, this leads to two points, and an FR:

  1. why does modifierKeysChanged() get called for mouse move events? If no changes have happened to the mouse buttons, or CAS buttons, surely this method shouldn’t be receiving callbacks?

  2. even with fixed code at my end, the cursor still visibly moves around. It snaps back correctly now, and I’m going to just blank the cursor to solve that problem for my application (blanking actually makes sense in this instance).

I’m guessing there is no way of overiding the mouse behaviour further up the event chain? Assuming no, it would probably be useful if components offered a constrainMouse() method, that when called with true does not allow the mouse outside of the component bounds. At the OS level, such behaviour can be implemented in a way that does not display weird movement artifacts. I’m drawing a blank on how it could be done for JUCE apps.


#3

eesh!! modifierKeysChanged isn’t supposed to get called that often…

But it’s not juce that’s doing it, it’s Windows! The damn thing is sending a key-down event every time the mouse moves… why???

I’ve added a bodge now, to check that the modifiers really have changed before it makes the callback.

I think that stopping the mouse dead in its tracks is probably not practical, it’d depend on getting the mouse events in the same vertical blanking interrupt and moving the pointer before it can get redisplayed… so not very easy. Blanking it is a good solution.


#4