Am Donnerstag, 13. Jänner 2022, 20:49:43 EAT schrieb Gabriel Ivăncescu:
Signed-off-by: Gabriel Ivăncescu gabrielopcode@gmail.com
For some reason I had to use AttachThreadInput, otherwise I couldn't set the window to foreground on Windows, even from the thread itself, it always failed... I don't know why but apparently this is a common "trick" to get around it.
I vaguely remember that I had some luck with minimizing and restoring the window, see test_wndproc() in d3d9/tests/device.c:
/* I have to minimize and restore the focus window, otherwise native d3d9 fails * device::reset with D3DERR_DEVICELOST. This does not happen when the window * restore is triggered by the user. */ expect_messages = tests[i].reactivate_messages; ShowWindow(focus_window, SW_MINIMIZE); ShowWindow(focus_window, SW_RESTORE); /* Set focus twice to make KDE and fvwm in focus-follows-mouse mode happy. */ SetForegroundWindow(focus_window); flush_events(); SetForegroundWindow(focus_window); flush_events(); /* WM_WINDOWPOSCHANGING etc arrive after SetForegroundWindow returns. */
Note that some of the quirks in that test are to make weird Linux WMs happy, but some are to make Windows do what we want.
Attaching the thread input might have unintended side effects, like both threads being considered foreground or so. Not sure though.
---
So let me recap the ddraw, d3d8, d3d9, dxgi tests for my understanding:
ddraw: The ddraw window itself needs to be foreground, otherwise it is not made topmost
d3d8: Any process window needs to be foreground for the device window to be made topmost
d3d9: The device window is made topmost, no matter what d3d9ex: The focus window needs to be foreground
dxgi: like plain d3d9, the window is made foreground no matter what.
What a mess...