[Bug 28884] keyboard input does not work properly for Sculptris

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Mar 14 02:53:21 CDT 2015


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

Sebastian Lackner <sebastian at fds-team.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://csillagpor.org/progr
                   |                            |amok/sculptris.exe

--- Comment #8 from Sebastian Lackner <sebastian at fds-team.de> ---
Thanks for providing the download url. Actually the following (very bad) hack
is sufficient to make the app working fine here (well, at least what I tested):

--- snip ---
diff --git a/dlls/user32/message.c b/dlls/user32/message.c
index eac4e4d..27a4988 100644
--- a/dlls/user32/message.c
+++ b/dlls/user32/message.c
@@ -3908,6 +3908,7 @@ BOOL WINAPI TranslateMessage( const MSG *msg )
         message = (msg->message == WM_KEYDOWN) ? WM_CHAR : WM_SYSCHAR;
         TRACE_(key)("%d -> PostMessageW(%p,%s,<x>,%08lx) for <x> in %s\n",
len, msg->hwnd,
             SPY_GetMsgName(message, msg->hwnd), msg->lParam, debugstr_wn(wp,
len));
+        return TRUE;
         for (i = 0; i < len; i++)
             PostMessageW( msg->hwnd, message, wp[i], msg->lParam );
     }
--- snip ---

The app calls PeekMessage and afterwards GetMessage in a loop. When the app
receives the first WM_KEYDOWN message, Wine translates this to a WM_CHAR
message. When the app tries to remvoe the WM_KEYDOWN message, it gets the
WM_CHAR message instead. Since the WM_KEYDOWN message is never removed new
WM_CHAR messages are generated all the time, which causes the app to hang.
Excerpt from the log, only relevant lines:

--- snip ---
371956.632:0009:Call
user32.PeekMessageA(0033fd6c,00000000,00000000,00000000,00000000) ret=0045b98e
371956.632:0009:trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd
0x20050 wp 41 lp 1e0001
371956.632:0009:Ret  user32.PeekMessageA() retval=00000001 ret=0045b98e
371956.632:0009:Call user32.TranslateMessage(0033fd6c) ret=0045b966
371956.632:0009:trace:key:TranslateMessage 1 ->
PostMessageW(0x20050,WM_CHAR,<x>,001e0001) for <x> in L"a"
371956.632:0009:Ret  user32.TranslateMessage() retval=00000001 ret=0045b966
371956.632:0009:Call user32.GetMessageA(0033fd6c,00000000,00000000,00000000)
ret=0045b972
371956.632:0009:trace:msg:peek_message got type 6 msg 102 (WM_CHAR) hwnd
0x20050 wp 61 lp 1e0001
371956.632:0009:Ret  user32.GetMessageA() retval=00000001 ret=0045b972
371956.632:0009:Call user32.DispatchMessageA(0033fd6c) ret=0045b980
0009:Call window proc 0x45ae90
(hwnd=0x20050,msg=WM_CHAR,wp=00000061,lp=001e0001)
0009:Ret  window proc 0x45ae90
(hwnd=0x20050,msg=WM_CHAR,wp=00000061,lp=001e0001) retval=00000000
371956.632:0009:Ret  user32.DispatchMessageA() retval=00000000 ret=0045b980

(now the same starts again, until PeekMessageA finally gets something else than
WM_KEYDOWN)

371956.633:0009:Call
user32.PeekMessageA(0033fd6c,00000000,00000000,00000000,00000000) ret=0045b98e
...
--- snip ---

Will have to take a closer look whats the difference to Windows here. Either
TranslateMessage() should behave differently, depending on if the message was
already translated before - or, more likely, messages are dequeued with
different priorities, which has the effect that WM_KEYDOWN is removed earlier.

Component is either user32 or wineserver.

-- 
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.



More information about the wine-bugs mailing list