windows: handle WM_POINTERCAPTURECHANGED events, fix maybe-undefined behavior. #11869
Conversation
…behavior. Fixes libsdl-org#11843. Fixes libsdl-org#11844.
| @@ -1195,6 +1198,8 @@ LRESULT CALLBACK WIN_WindowProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lPara | |||
|
|
|||
| case WM_POINTERDOWN: | |||
| case WM_POINTERUP: { | |||
| returnCode = 0; // always mark this event handled, so it doesn't go to DefWindowProc (see #11843). | |||
There was a problem hiding this comment.
It's likely that always handling these messages might regress touch input. Since SDL is lying to windows about handling the PT_TOUCH messages, even though it's not doing anything with them (i.e. not sending to the application).
The two issues I opened show violation of the documentation, but any real-world impact is untested. I invite you to you to test some of the hypothetical problems I listed. I'm currently travelling and don't have access to my touchscreen monitor and graphics tablet to test. Sorry if my original issue description is unclear about this.
There was a problem hiding this comment.
Yeah, I might back this part out for now and wait for bug reports to arrive...I'm not really clear that this is even what Microsoft is asking me to do, honestly.
There was a problem hiding this comment.
Microsoft likely wants you to handle all pointer events properly, but SDL already has perfectly good touch handling via WM_TOUCH. I'm fine with only the WM_POINTERCAPTURECHANGED change going in (please update the PR title and description accordingly). I'll try to borrow some graphics tablets and touchscreen monitors and do some testing as set out in #11843.
|
Put in the WM_POINTERCOUNTERCHANGED fixes in 0180ca5. Dumping the rest for now. |
Fixes #11843.
Fixes #11844.
CC @Susko3, does this cover it?