Right mouse click while rotating a knob = control stuck into permanent editing

Developer VSTGUI
#1

Hello,

some of my plug-in testers have reported a strange issue regarding knobs and mouse clicks.
Basically, if you accidentally click the right mouse button while you’re turning a knob, the knob gets stuck into editing and starts following the mouse pointer until you close the GUI.
I know that it’s a weird use case, but it can be annoying.

It seems like when you click the mouse right button, the endEdit() from the previous mouse movement (ex. rotating the knob) is never called, so the editing counter never returns to zero and this causes the strange behavior.

Is this a known issue? Can anyone else confirm the problem? I can replicate it easily in both Windows and Mac (any host, so far), but I’d like to be sure it’s related to VSTGUI, since I did some customizations but nothing that should interfere with knobs behavior in any way.

I’m using version 4.3.

Thanks in advance,
Federico Berti - Ignite Amps

#2

Hi Federico,
you’re right, it looks like that this can happen.
The fix for this is to add the following lines at the beginning of CViewContainer::onMouseDown (…) :

	if (pImpl->mouseDownView)
	{
		// we ignore secondary buttons when another button is already in a pressed state
		return kMouseEventHandled;
	}

Cheers
Arne

#3

Thanks for the fix, Arne, but I’m afraid the problem is not completely gone yet…

This fix works if you click the right mouse button while the pointer is still inside the CViewContainer of the knob, but when moving the cursor, if you end up into another CViewContainer or outside the VSTGUI window (it can happen if you have controls on a footer or a header, like in my case), the editing gets stuck again.
Good thing is that this time if you click again the right or left mouse button while inside the knob CViewContainer, the editing stops, so there is no need to close the GUI.

Way better than before, but not perfect yet :smiley:

#4

Thanks for reporting back.
I will have a look how to make a better change.

Cheers
Arne

#5

Anything wrong with doing the same thing, but at CFrame level?
Seems to work, but I don’t know the library enough in depth to evaluate the impacts of the change…

#6

So, I think the real fix is this :

//-----------------------------------------------------------------------------
void CViewContainer::setMouseDownView (CView* view)
{
	if (pImpl->mouseDownView && pImpl->mouseDownView != view)
	{
		// make sure the old mouse down view get a mouse cancel or if not implemented a mouse up
		if (auto cvc = pImpl->mouseDownView->asViewContainer ())
			cvc->setMouseDownView (nullptr);
		else if (pImpl->mouseDownView->onMouseCancel () == kMouseEventNotImplemented)
		{
			CPoint p = pImpl->mouseDownView->getViewSize ().getTopLeft () - CPoint (10, 10);
			pImpl->mouseDownView->onMouseUp (p, 0);
		}
	}
	pImpl->mouseDownView = view;
}

What do you think ?

Cheers
Arne

#7

Ok, I couldn’t test this fix on my VSTGUI version, so I’ve updated to the latest master version on GitHub.

I confirm that it works when moving the mouse cursor into another CViewContainer.
If you go outside the plug-in window, when the right click gets captured by the host (ex. you get a popup menu in Reaper or Logic), the editing remains stuck.
I don’t know if we can do something about this, or is outside our control, honestly… thoughts?

Thanks for the quick fix

#8

Is this last issue on both macOS and Windows ?

#9

I’ve tested it on OSX, I’ll report the result on Windows by monday.

#10

Works correctly on Windows on the same scenario in Reaper, seems like an OSX related issue.