diff options
author | Nicholas Rishel <rishel.nick@gmail.com> | 2020-06-10 02:33:33 +0300 |
---|---|---|
committer | Nicholas Rishel <rishel.nick@gmail.com> | 2020-10-31 02:29:04 +0300 |
commit | d9b0ef2de43f70979ffcf370ca371cac897adf7b (patch) | |
tree | 435f112a63e580b9e91ca568fbc3767b8d77b6d5 | |
parent | 5badaa83903bdb2367aa35701291b38e60ee45b5 (diff) |
Finish the comment's thought explaining pessimistic button ups events for
Wintab.
-rw-r--r-- | intern/ghost/intern/GHOST_SystemWin32.cpp | 11 |
1 files changed, 9 insertions, 2 deletions
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; |