Some meta suggestions regarding this PR:

• Change PR title to 'Handle WM_POINTER* events in favor of WM_TOUCH'.
• Add 'Fixes Handle WM_POINTER* events in favor of WM_TOUCH #975' to the description.
• I got rid of the merge commit and put the above suggestions into the commit message at felixrabe/winit@dc9a7f4effab8. You can force-push to that if you like.

Hey folks, I noticed you were on the windows testing list.

@0xpr03, and @FliegendeWurst Can one of you two test this on windows 7?

@arthrp, and @notriddle Can one of you two test this on windows 8 or 10?

Thanks.

Build & Tests pass on win 7

Update: All examples are broken with (window example):

error: process didn't exit successfully: target\debug\examples\window.exe (exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND)

RUST_BACKTRACE doesn't output anything, so if there's a way, tell me how I can provide more information.

As i've mentioned, the functions needed by these events are not available on Windows 7 and older. I couldn't find anything about how Rust links FFI functions and I assumed that it uses dynamic linking. Because handling WM_TOUCH already breaks pre-Windows 7 compatibility, i guess that it's not priority for winit to support Windows XP.

So we should load those functions dynamically through LoadLibrary and GetProcAddress. I've found an example usage of GetProcAddress in 'platform_impl/windows/dpi.rs', where a 'get_function' macro is defined to ease this process. Maybe this macro and it's accompanying function should be moved into 'platform_impl/windows/util.rs' and made visible within the whole module.

We probably don't want support for anything older, but windows 7 is still supported and will be for longer on the industry side, so I'd personally not drop w7 support for now.

@zegentzy thanks for pinging testers!

@dam4rus Sorry about the delay in reviewing. The dynamic function loading machinery in dpi should indeed be used for this, and moving it into util is a good idea.

@Osspial Should i create a separate PR for moving the dynamic function loading macro?

@dam4rus Nah, adding it in this PR is fine.

@0xpr03 It should work now. Can you test it?

@dam4rus yes, current version works with examples

I'll go ahead and merge this now. Thank you for implementing this!

Actually, one last thing - does this add multitouch support? If so, the relevant line in the feature matrix should get updated.

WM_TOUCH already handled multiple touch points (AFAIK) and so does WM_POINTER. So, it depends on what you mean by multitouch support? This just sends individual touch events for every touch point like the WM_TOUCH implementation. The client can store these events to handle simultaneous touch points. Even so, it's kinda hard to tell what's a "touch event frame" with the current implementation.

Ah, I suppose that should just be marked with a checkmark instead of a question mark, then. I'll merge this now and correct that.