[Bug 31899] No keyboard input in La-Mulana remake (GetKeyState should behave similar to GetAsyncKeyState for specific window messages / queue states)

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=31899

Sebastian Lackner <sebastian at 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 at 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).

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.