Open scottmudge opened 6 years ago
Hi, I'm very happy about your contribution! It would be great to have touch support in Gainput for Windows. There is just one thing: I feel this adds a little too much platform-specific code to GainputInputManager.cpp. Do you think that could be changed?
Cheers, Johannes
Hi Johannes,
It could be removed if you like, but the automatic creation and latching of a WinProc by providing a simple HWND handle helps immensely with anyone where they only have an HWND. For instance, using GLFW, one would have to in their project code implement a new WinProc function, deal with all the appropriate data passing to parent functions, integrated Gainput there, etc., it just gets messy. Now all that needs to be done is for the user to simply pass the native handle from GLFW to the gainput input manager constructor, and everything is taken care of automatically.
Ideally there would be multiple versions of the input manager for each native platform, since the way each platform manages input is significantly different (at least between Unix and Windows), but since there is no inheritance, I just stuck the code in the main input manager source file.
I did make sure to put the appropriate preprocessor guards around the native code, however.
It's really up to you. You can omit all of the native code and just implement the GainputInputDeviceTouchWin.h file. I just thought I'd make it easier for people using GLFW or other libraries where they really only have Window handles available.
All the best, Scott
Gainput appeared to lack touch/multi-touch support for Windows (which is increasingly seeing touch-based input, e.g., for the Surface tablets).
I added a native wrapper for touch support for Windows.
I also added in the ability to pass an HWND handle to the InputManager constructor (only available on Windows builds), which will hook in a message pump via custom WNDPROC callback to automatically pass window MSGs to the InputManager::HandleMessage() function. This is useful for when the user does not want to place a HandleMessage() call in their own message handler, or for when the user does not have access to the native message handler, as with many GLFW implementations.
Thanks!