https://bugs.winehq.org/show_bug.cgi?id=31899
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |wineserver Depends on| |27238 Summary|No keyboard input in |No keyboard input in |La-Mulana remake |La-Mulana remake | |(GetKeyState should behave | |similar to GetAsyncKeyState | |for specific window | |messages / queue states)
--- Comment #12 from Sebastian Lackner sebastian@fds-team.de --- As already suspected this issue is really very similar to bug 27238. I prefer to keep the separate anyway because they can probably be fixed independently.
The problem is that the GetKeyState(...) implementation of Wine is completely wrong (well, and the MSDN description also). Some testing on Windows 7 turns out that it is not true, that the returned key state is a saved state when the message was originally added. This is only true for specific keyboard-related window messages, but for the rest GetKeyState behaves identical to GetAsyncKeyState, and even recognizes keyboard events typed in into other applications. We'll have to write some additional tests to figure out more exactly how Windows decides what to use.
The reason why the fix for bug 27238 doesn't work in this case: An OLE apartment is initialized on the same thread, and this implicitly creates a window, so the thread has already a message queue. Nevertheless, even when explicitly creating a window it still works on Windows, so the Wine bug must be in GetKeyState itself. Component is most likely the server (in combination with user32).