At 10:02 PM 7/18/00 +0200, you wrote:
>There's a problem in the current message queue code, which shows up in
>games (and probably some installers too?)... it doesn't accept mouse input
>before the user has hit a key at least once.
>
>I've tracked it down to the message queue code, this condition:
>
>warn:msg:QUEUE_WakeSomeone couldn't find queue
>
>and this happens because QUEUE_WakeSomeone looks through all queues to
>find a queue with an appropriate wake mask, then sets its wake bits to
>wake it up. But the application is in a PeekMessage loop, so it never
>waits, and so no wake masks are set, so QUEUE_WakeSomeone can't do
>anything. Furthermore, PeekMessage only retrieves hardware events if the
>queue's wake bits are set, and since QUEUE_WakeSomeone didn't set any
>queue's wake bits, nothing happens. All mouse events just get queued but
>never read out before something else happens... (like the user hitting a
>key instead, but I don't know why keypresses don't also get stuck, or why
>mouse events work afterwards.)
[first I CC'ed my previous reply to wine-patches; big mistake of course]
Could the following hack change anything in your problem
(for the worse, of course :-); the idea is to not allow keyboard
messages for disabled windows)
--- message.c.orig Sun Jul 16 09:06:11 2000
+++ message.c Thu Jul 20 22:30:18 2000
@@ -382,6 +382,7 @@
if( message < WM_SYSKEYDOWN )
message += WM_SYSKEYDOWN - WM_KEYDOWN;
}
+ if (!IsWindowEnabled(WIN_GetTopParent(hWnd))) hWnd = 0;
pWnd = WIN_FindWndPtr( hWnd );
if (pWnd && (pWnd->hmemTaskQ != GetFastQueue16()))
{
Gerard
