I’ve noticed some quirky multi-touch behaviour and would be grateful for any feedback. For reference, I’m on Windows 10 and it’s the same for both standalone apps and VST plugins. I don’t know whether it’s platform-specific or a general thing at this stage.
Single touch and mouse inputs work very nicely side by side, but as soon as multi-touch input is introduced, the mouse input recognition stops altogether (clicks, hovers and so on do nothing), while single touches still work as before. Is there something I’m doing wrong, or could this be improved?
After reading various threads here on the topic, I’ve come to appreciate that Windows generally treats single touch and mouse events as basically equivalent but then things change with multi-touch, so I imagine it’s some funky statefulness in this area, such as a one-way switch being thrown (no) or a blocking list of active touches (yes, see below) that isn’t ever fully cleared?
Update: after some quick digging, I’ve found some details that seem to confirm my hypothesis:
true(incorrectly) after any multi-touch events have occurred, which blocks any subsequent mouse events from firing normally thereafter
- it seems that
Desktop::getInstance().getMouseSources()increases from the initial 1 to 1 + maximum number of simultaneous touches received; this number never decreases
buttonState.isAnyMouseButtonDown()) always returns
truefor these extra mouse sources, except for the final one which is duly cleared to
So it would appear that a proper inventory and suitable clearing of all “mouse sources” is what’s required here. I’ll keep looking into it.