Commit ccf430eb authored by Stefan Dösinger's avatar Stefan Dösinger Committed by Alexandre Julliard

user32: Silently ignore temporary foreground loss.

The basic problem is this: Thread A has a window W1 that is it's focus window and the system-global foreground window. At some point thread A stops processing messages. After that, thread B creates a window W2 and makes it the foreground window. Thread B later on makes W1 (from Thread A) the foreground window again. After restoring W1 as the foreground window, Thread A processes window messages again. Two WM_WINE_SETACTIVEWINDOW messages are in the queue, one for losing the foreground thread propery and one for restoring it. The first one will generates a WM_ACTIVATEAPP(0) message, which causes D3D to minimize the game window. The included test shows that Windows doesn't deliver any WM_ACTIVATEAPP messages if the thread stopped being the foreground thread and re-gained that property between two message processing calls. It isn't implemented with a plain WM_ACTIVATEAPP filter, the manually injected message in the test still gets through. Signed-off-by: 's avatarStefan Dösinger <stefan@codeweavers.com> Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
parent f3a0ac8d
......@@ -1872,6 +1872,7 @@ static LRESULT handle_internal_message( HWND hwnd, UINT msg, WPARAM wparam, LPAR
return EnableWindow( hwnd, wparam );
case WM_WINE_SETACTIVEWINDOW:
if (is_desktop_window( hwnd )) return 0;
if (!wparam && GetForegroundWindow() == hwnd) return 0;
return (LRESULT)SetActiveWindow( (HWND)wparam );
case WM_WINE_KEYBOARD_LL_HOOK:
case WM_WINE_MOUSE_LL_HOOK:
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment