![]() 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: Stefan Dösinger <stefan@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org> |
||
---|---|---|
.. | ||
Makefile.in | ||
broadcast.c | ||
class.c | ||
clipboard.c | ||
combo.c | ||
cursoricon.c | ||
dce.c | ||
dde.c | ||
dialog.c | ||
edit.c | ||
generated.c | ||
input.c | ||
listbox.c | ||
menu.c | ||
monitor.c | ||
msg.c | ||
resource.c | ||
resource.rc | ||
scroll.c | ||
static.c | ||
sysparams.c | ||
test_mono.bmp | ||
text.c | ||
uitools.c | ||
win.c | ||
winstation.c | ||
wsprintf.c |