From d9b0ef2de43f70979ffcf370ca371cac897adf7b Mon Sep 17 00:00:00 2001 From: Nicholas Rishel Date: Tue, 9 Jun 2020 16:33:33 -0700 Subject: Finish the comment's thought explaining pessimistic button ups events for Wintab. --- intern/ghost/intern/GHOST_SystemWin32.cpp | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'intern') diff --git a/intern/ghost/intern/GHOST_SystemWin32.cpp b/intern/ghost/intern/GHOST_SystemWin32.cpp index ca2c6c576fa..aa282c73c92 100644 --- a/intern/ghost/intern/GHOST_SystemWin32.cpp +++ b/intern/ghost/intern/GHOST_SystemWin32.cpp @@ -1046,8 +1046,15 @@ GHOST_TSuccess GHOST_SystemWin32::processWintabEvents(GHOST_TEventType type, // // Wintab button up events may be handled during WM_MOUSEMOVE, before their corresponding // WM_*BUTTONUP event has fired, which results in two GHOST Button up events for a single Wintab - // associated button event. Because Wintab and their associated Windows mouse events are handled - // asynchronously, and there's no way to turn off + // associated button event. Alternatively this Windows button up event may have been generated + // from a non-stylus device such as a button on the tablet pad and needs to be handled for some + // workflows. + // + // The ambiguity introduced by Windows and Wintab buttons being asynchronous and having no + // definitive way to associate each, and that the Wintab API does not provide enough information + // to differentiate whether the stylus down is or is not modified by another button to a + // non-mouse mapping, means that we must pessimistically generate mouse up events when we are + // unsure of an association to prevent the mouse locking into a down state. if (unhandledButton) { if (!window->wintabSysButPressed()) { GHOST_TInt32 x, y; -- cgit v1.2.3