-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Oh, and when you add to all this the strange WM_VISIBLE / WM_EX_TOPMOST behavior on the *second* device creation, the S_PRESENT_MODE_CHANGED on Reset to windowed (needs a second reset), the fact that I have do minimize and restore the device window to reliably convince d3d9ex that it has focus back (about 5% of the time it works without that) and some other bugs I've seen in my experiments I'm convinced that native d3d9ex is pretty broken.
Am 2014-10-16 13:30, schrieb Stefan Dösinger:
Am 2014-10-16 00:46, schrieb Matteo Bruni:
I also tried to copy the d3d9 test from "wined3d: Set the device window size on focus window activation." to d3d9ex and it looks like it always passes for me. Was that the test you were mostly interested in?
It fails about 50% of the time on my Vista machine (Geforce 7400). Most of the time the WM_SIZE message is missing, but I've had some really rare runs where the entire WM_DISPLAYCHANGING/WM_DISPLAYCHANGED part is missing.
The really interesting thing is the test in the last patch labeled "unfinished". It's not the hidden window part that's tricky - this is consistent - but the fact that the test adds a second focus loss / focus restore cycle. I've had difficulties convincing d3d9ex that it has the focus back. This works now. In my past patchset I did not manage to convince native d3d9ex that it had lost focus the second time. I don't know yet if the device window hiding and showing fixes that.
Focus changes are reliable in d3d9ex for my test applications when I press alt-tab, but not when I use SetForegroundWindow. I even tried to set the foreground window to the window of a different process and back from there, but this does not help either. User alt-tab is reliable though. I have not seen a difference in the messages passed to the device and focus windows, so I suspect there is some back channel talk going on between d3d9, user32 and explorer.exe (or some other central component involved with focus handling). Any ideas would be welcome.
There is one difference in the messages I spotted: On reactivation with SetForegroundWindow the WM_NCACTIVATE message instructs the window to paint an inactive title bar. The window does receive focus though. I believe that this is a symptom rather than the cause. No d3d involvement is needed to see this behavior.