enableUnboundedMouseMovement leads to shown Cursor in Cubase

General JUCE discussion
1

Hi,
I encountered a problem in Cubase Win32, when Controls like a Slider set the enableUnboundedMouseMovement to true and the Cursor should not be kept visible.

If you move the Mouse beyond the Bounds of the topLevelComponent (the editor window), the Cursor becomes visible and stays visible even if the MousePosition is set to somewhere over the juce editor afterwards.
This is really confusing for the user because this leads to a jumping Cursor that is sometimes visible and sometimes not and that doesn’t seem to be related to the adjusted Control Component.

In all other hosts I tested enableUnboundedMouseMovement (true, false) works as expected.

Any ideas how to fix this?

Thanks

2

Very odd - I can only guess that cubase is forceably setting the cursor shape when it moves outside a window… Can’t really think of how you’d do a workaround for it…

3

It should work with Cubase in principal, too. For example the Sonalksis TBK3 has a rotary working exactly this way and has no problems with Cubase.

It would be a real pity if I can’t get rid of this because all of my custom components work this way and I’m quite satisfied with their feel and scaling. Cubase is just too popular to discount it.

Anybody else a hint for me where to start? It should not be impossible to get this to work.

4

Well, if someone else has done it, then I’m sure we can figure out how to make it work… Maybe it’s just a case of moving the hidden mouse pointer back to keep it within the window?

5

That was my first thought, too. I modified the Components to move the mouse back to the center of the Component that was dragged. First I tried to set the MousePosition when it leaves the editor bounds. Than I tried to set the position, when the mouse leaves the bounds of the drag Component.

The problem is, it works with slower mouse movements, but when you move the mouse quickly, so that it leaves the bounds of the editor before it is set back in the mouseDrag callback (that’s where I put the code for repositioning) the cursor is shown and won’t be hidden even if the mouse doesn’t leave the editor bounds while the mouse is still beeing dragged afterwards.

Perhaps there is a way to prevent the mouse from being moved out of the editor area, or a way to hide the cursor again after setting the cursor position in the drag callback. Maybe there is another point where the repositioning code should be placed instead of the drag callback?

Hope that helps to make the problem a bit clearer.

Thanks

6

Ok… try this cunning tweak to the component code:

[code]void Component::internalUpdateMouseCursor (bool forcedUpdate) throw()
{
ComponentPeer* const peer = getPeer();

if (peer != 0)
{
    MouseCursor mc (getMouseCursor());

    if (isUnboundedMouseModeOn && (unboundedMouseOffsetX != 0
                                    || unboundedMouseOffsetY != 0
                                    || ! isCursorVisibleUntilOffscreen))
    {
        mc = MouseCursor::NoCursor;
        forcedUpdate = true;
    }

etc…

[/code]

I’ve not tried it, but that should force it to continuously hide the mouse whenever it moves…

7

That tweak in combination with the repositioning of the cursor almost does the trick, but not completely.

If you do some faster mouse movements, and the mouse leaves the bounds of the editor window it is still shown, but now it is hidden again very quickly instead of staying visible like before this tweak. I think first there is a Cubase callback that makes the mouse visible, directly followed by the juce callback to make it invisible again. The result is better than before but there is still some unattractive flickering effect on faster mouse movements.

8

Well, I figured it out, things are working fine, now. Putting the following code at the end of the mouseDrag callback (more precisely at the end of the code of the style that uses unboundedMouseMovement), in addition to your tweak fixes the Cubase problem and I didn’t notice any unwanted side effects in other hosts.

beginDragAutoRepeat (2); if(e.x <= 0 || e.x >= e.eventComponent->getWidth() || e.y <= 0 || e.y >= e.eventComponent->getHeight()) { Desktop::setMousePosition (e.getMouseDownScreenX(), e.getMouseDownScreenY()); e.eventComponent->getMouseXYRelative(mouseXWhenLastDragged, mouseYWhenLastDragged); }

It would be nice if you could add the tweak you suggested for the Component class to the next version, if that doesn’t break anything else, so people with that problem don’t have to do this tweak evertime they check out a new version.

Thanks for your help.

9

Interesting. I’m not crazy about the idea of starting a beginDragAutoRepeat though, as that’ll stay running and may interfere with people’s own use of that feature. Doesn’t it work without that line of code?

10

Unfortunetly no. As described above, Cubase seems to get something like a mouseEnter what makes the Cursor visible, between two calls to the juce mouseDrag, if the mousePosition leaves the bounds of the editor. So the Cursor is flickering if I don’t use the beginDragAutoRepeat. I know it’s not a clean solution but it works with my custom Components. If we can’t figure out how to prevent Cubase from getting these kind of mouseEnter respectively showCursor events, this could be a workaround. I don’t ask you to add the beginDragAutoRepeat to the juce Components. It’s just the “forcedUpdate = true;” line in the Components class. I’ll keep on trying to find a clean solution and will let you know when I had success.