Site navigation

restoreMouseIfHidden request

General JUCE discussion
#1


In restoreMouseIfHidden(), there is a correction of the mouse position that was introduced to correct the behaviour described here : http://www.juce.com/forum/topic/rotary-verticaldrag/horizontaldrag-bug
(so that the rotary sliders do not jump when the modifier key is released)


That is ok if ones plays with the modifiers, but that mouse position correction is really annoying if you set the velocity based mode to true by default, because the mouse will never be to the last mouse down position, that is will never go back to the center of the knob.
To correct this behaviour, the cursor position correction must only take place when restoreMouseIfHidden is called from modifierKeysChanged(), not by mouseUp()

a quick way to test it is just adding a parameter : void restoreMouseIfHidden (bool correctPosition)

and adding a condition to the test line 1946 :  if (isRotary() && correctPosition)

 

Don't you think?
 

#2

Ok, thanks. Your fix doesn't sound quite right to me, but I'll take a look.

#3

thanks for the commit!

#4


actually that does not work so well :
If the knob is in sensitivity mode by default, and if you use it without any modifier key, the cursor position is still badly corrected and not set back to where it was on mouse down.
 

#5

Well, it constrains it so that it snaps back to be within the component's bounds. Your suggestion made little sense to me because it would be snapping to the position returned by getLinearSliderPos() when the slider was not linear.

#6

<blockquote>it constrains it so that it snaps back to be within the component's bounds</blockquote>

that's not always the case unfortunately. You can just test it in the widget demo :

if you set the rotary slider in velocity-sensitive mode and with "use up-down dragging", set the knob to its max, release the mouse, clic it again and drag it fast enough to its minimum the cursor will be out of bounds. that's even more flagrant in "left to right + up to down". I think it makes sense to have it back where you clicked before you dragged.

#7

No... that doesn't happen. It doesn't sound like you've got the latest code?

I used this:

                    mousePos = owner.getScreenBounds().getConstrainedPoint (mousePos);

..so it's just not possible for it to be outside the slider bounds.

#8

Yes, I just checked again and I'm using the latest code. but I think understood what happens :

The cursor is really set at the extreme border of the bounds. ok.

but the slider "does not see" that the mouse is over it, and won't be selected again if you just click. you have to move the mouse a bit for the slider to take the mouse into account again. So it behaves as if the mouse was out of it.

#9

Ah, I see. Ok, well I guess the simplest thing to do is to just reduce the region by a few pixels.

#10

hum jules, there's something worst i'm sorry. the knob may jump back sometimes. To reproduce in the widget demo :

- right click the knob and set rotary mode to "up-down".

- click on the knob.

- press ctrl

- drag up for a while

- release ctrl (but not the mouse)

- drag up again -> the slider jump back to were it was at first.

 

#11

Ok, that should work now.