fvwm d3d test failures

[Stefan Dösinger]

Hi Alexandre,

Since I currently have my head wrapped around the d3d message tests I'd
like to give your fvwm2 test failures another try. Can you send me the
test failures you currently see?

Here I see one failure mostly reliably (~90% of all runs) with fvwm2 in
focus follows mouse mode. I think the particular test is not too
important, so we can disable it, but I'd like to verify first that it is
the same issue you have.

Cheers,
Stefan

[Alexandre Julliard]

Stefan Dösinger  writes:
> Hi Alexandre,
>
> Since I currently have my head wrapped around the d3d message tests I'd
> like to give your fvwm2 test failures another try. Can you send me the
> test failures you currently see?
>
> Here I see one failure mostly reliably (~90% of all runs) with fvwm2 in
> focus follows mouse mode. I think the particular test is not too
> important, so we can disable it, but I'd like to verify first that it is
> the same issue you have.

I'm usually running tests with this patch, which avoids the failure for
me. If you have a better fix I'd be interested...

diff --git a/dlls/d3d9/tests/d3d9ex.c b/dlls/d3d9/tests/d3d9ex.c
index a3cbdbfadfff..4dd2fe41111d 100644
--- a/dlls/d3d9/tests/d3d9ex.c
+++ b/dlls/d3d9/tests/d3d9ex.c
@@ -2890,14 +2890,17 @@ static void test_wndproc(void)
         ShowWindow(device_window, SW_HIDE);
         flush_events();

-        expect_messages = focus_loss_messages_hidden;
-        windowposchanged_received = 0;
-        SetForegroundWindow(GetDesktopWindow());
-        ok(!expect_messages->message, "Expected message %#x for window %#x, but didn't receive it, i=%u.\n",
-                expect_messages->message, expect_messages->window, i);
-        ok(!windowposchanged_received, "Received WM_WINDOWPOSCHANGED but did not expect it, i=%u.\n", i);
-        expect_messages = NULL;
-        flush_events();
+        if (GetForegroundWindow() == focus_window)
+        {
+            expect_messages = focus_loss_messages_hidden;
+            windowposchanged_received = 0;
+            SetForegroundWindow(GetDesktopWindow());
+            ok(!expect_messages->message, "Expected message %#x for window %#x, but didn't receive it, i=%u.\n",
+               expect_messages->message, expect_messages->window, i);
+            ok(!windowposchanged_received, "Received WM_WINDOWPOSCHANGED but did not expect it, i=%u.\n", i);
+            expect_messages = NULL;
+            flush_events();
+        }

ret = EnumDisplaySettingsW(NULL, ENUM_CURRENT_SETTINGS, &devmode);
         ok(ret, "Failed to get display mode.\n");

[Stefan Dösinger]

Am 2017-10-12 um 17:21 schrieb Alexandre Julliard:
> I'm usually running tests with this patch, which avoids the failure for
> me. If you have a better fix I'd be interested...

Looks like you have the same failure as I do. d3d8:device and
d3d9:device have the same test, and they fail for for me too, although
not as often as the d3d9ex one.

I'd just have removed the entire test, so no, I don't have a better fix
:-) . I'll try to understand better how the focus ends up with the focus
window, or rather, why other WMs and Windows appear to keep the hidden
device window focused.

(Replacing ShowWindow(SW_HIDE) with SetWindowLong(GWL_STYLE, old_style &
~WS_VISIBLE) may keep the device window focused and still trigger the
same d3d9 behavior, but it feels like a hack)

[Uwe Bonnes]

> > > > > "Stefan" == Stefan Dösinger  writes:

Stefan> Hi Alexandre, Since I currently have my head wrapped around the
    Stefan> d3d message tests I'd like to give your fvwm2 test failures
    Stefan> another try. Can you send me the test failures you currently
    Stefan> see?

Stefan> Here I see one failure mostly reliably (~90% of all runs) with
    Stefan> fvwm2 in focus follows mouse mode. I think the particular test
    Stefan> is not too important, so we can disable it, but I'd like to
    Stefan> verify first that it is the same issue you have.

Stefan,

I still work with fvwm2 and "click to focus". Since ages, I have a problem
with Switchercad http://www.linear.com/designtools/software/#LTspice where
the boxes to edit device properities and similar things don't get focus on
click. This does not happen always, but often. I think clicking a wine
unrelated window and clicking back the ltspice window gives the expected
focus.

Maybe this is related to the problem above...

Bye