Re: [PATCH v6 4/6] d3d8/tests: Test for window changes when it's not foreground.

[Gabriel Ivăncescu]

On 18/01/2022 13:03, Stefan Dösinger wrote:
> Am Donnerstag, 13. Jänner 2022, 20:49:43 EAT schrieb Gabriel Ivăncescu:
> > Signed-off-by: Gabriel Ivăncescu
> >
> > 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.

Thanks for the tip, I'll try something with it then.
> 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...

Yep. There's also visibility affecting d3d8 and d3d9ex (i.e. hidden 
focus windows always do changes, even if the foreground condition does 
not apply). This doesn't apply to ddraw, so it was worth mentioning, 
although we *do* have existing tests for this, because most of the prior 
tests are done on hidden windows, so they're implicitly tested already.

This is also the reason for the ddraw regression; since at that point we 
only had tests on hidden windows, it was implicitly always treated as 
"not foreground" (because ddraw doesn't special case hidden windows), 
and so unconditionally applied the NOWINDOWCHANGES flag.