Mousewheel edits affect multiple controls on Windows

I’ve had multiple users reporting that on some Windows setups the mousewheel affects multiple (non-overlapping) controls and I finally had the chance to boil down the issue. I’m sure that this is in fact a bug in VSTGUI and not related to my particular implementation whatsoever, see below.

It can be reproduced on e.g. Windows 10, Cubase 8 or newer in 64 Bits and only occurs when the zoom factor is set to anything other than 1.0 via CFrame::setZoom().

Here is a quick demonstration of what happens:

Below is a VSTGUI only code snippet that outlines a minimal editor implementation that allows to reproduce the issue. If you play around with the two knobs a little, it should be easy to hit a state in which both knobs are “linked”. I haven’t yet figured out any further systematics except for the prerequisites mentioned above. This does not happen for normal click+drag editing, so I’m guessing the root probably sits in the cases WM_MOUSEWHEEL and WM_MOUSEHWHEEL in Win32Frame::proc() or the IPlatformFrameCallback::platformOnMouseWheel() implementation.

static const double scale = 2;

static const CCoord width = 200;
static const CCoord height = 100;

class TestView :
	public VSTGUIEditor,
	public IControlListener
{
public:
	TestView(EditController* controller) : VSTGUIEditor(controller)
	{
		rect.left = 0;
		rect.top = 0;
		rect.right = int32(scale * width);
		rect.bottom =  int32(scale * height);
	}

	virtual ~TestView()
	{
	}

	virtual bool PLUGIN_API open(void* parent, const PlatformType& platformType = kDefaultNative)
	{
		if(frame)
			frame->forget();

		CRect size(0, 0, width, height);
		frame = new CFrame(size, this);

		if(frame && frame->open(parent, platformType))
		{
			frame->setBackgroundColor(kBlackCColor);

			// Add two knobs to demonstrate the odd mousewheel behavior
			CRect knobSize(0, 0, 0.8*height, 0.8*height);

			knobSize.centerInside(size);
			knobSize.offset(-knobSize.getWidth()/2.0 - 4.0, 0);
			auto knob1 = new CKnob(knobSize, this, -1, nullptr, nullptr);
			knob1->setDrawStyle(CKnob::kCoronaDrawing);
			knob1->setCoronaColor(kRedCColor);
			knob1->setCoronaInset(2.0);
			knob1->setHandleLineWidth(4.0);
			knob1->setValue(0.5f);
			frame->addView(knob1);

			knobSize.centerInside(size);
			knobSize.offset(+knobSize.getWidth()/2.0 + 4.0, 0);
			auto knob2 = new CKnob(knobSize, this, -1, nullptr, nullptr);
			knob2->setDrawStyle(CKnob::kCoronaDrawing);
			knob2->setCoronaColor(kRedCColor);
			knob2->setCoronaInset(2.0);
			knob2->setHandleLineWidth(4.0);
			knob2->setValue(0.5f);
			frame->addView(knob2);

			// Mousewheel editing works flawlessly when scale == 1.0
			frame->setZoom(scale);

			return true;
		}

		return false;
	}

	virtual void PLUGIN_API close()
	{
		if(frame)
		{
			frame->close();
			frame = nullptr;
		}
	}

	virtual void valueChanged(CControl* pControl)
	{
		// Do nothing here...
	}
};

Best,
Ray

It looks like that there are two mouse wheel events coming, one from the WindowProc and one from VSTGUIEditor::onWheel(…). I don’t know why this is dispatched twice on Windows. You may disable the code in VSTGUIEditor::onWheel() for now.

Cheers,
Arne

Hi Arne,

Thanks for getting back on that one so quickly.

I don’t get why this causes the decribed behavior, but I will certainly try that.

Best,
Ray