Henri Verbeet hverbeet@codeweavers.com writes:
dlls/d3d8/tests/device.c | 22 ++++++++++++++++++---- 1 files changed, 18 insertions(+), 4 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so device.c && touch device.ok device.c:1616: Test failed: Expected focus 0x60100, got (nil). device.c:1618: Test failed: Expected foreground window 0x60100, got (nil). make[1]: *** [device.ok] Error 2
On 19 March 2010 16:01, Alexandre Julliard julliard@winehq.org wrote:
It doesn't work here:
../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so device.c && touch device.ok device.c:1616: Test failed: Expected focus 0x60100, got (nil). device.c:1618: Test failed: Expected foreground window 0x60100, got (nil). make[1]: *** [device.ok] Error 2
Should I just disable those tests? The reason the tests were originally todo_wine is that we got the WM_WINE_SETACTIVEWINDOW caused by the other thread after CreateDevice() switched the foreground window back to this thread. The extra event processing before create_device() makes that message get handled earlier, at least for me.
Henri Verbeet hverbeet@gmail.com writes:
On 19 March 2010 16:01, Alexandre Julliard julliard@winehq.org wrote:
It doesn't work here:
../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so device.c && touch device.ok device.c:1616: Test failed: Expected focus 0x60100, got (nil). device.c:1618: Test failed: Expected foreground window 0x60100, got (nil). make[1]: *** [device.ok] Error 2
Should I just disable those tests? The reason the tests were originally todo_wine is that we got the WM_WINE_SETACTIVEWINDOW caused by the other thread after CreateDevice() switched the foreground window back to this thread. The extra event processing before create_device() makes that message get handled earlier, at least for me.
Reliably testing the foreground window is pretty hard, since the window manager is in charge of it. The user32 tests try, but despite their best efforts they still fail sometimes. So if you don't absolutely need that test, removing it is probably best.
On 19 March 2010 16:31, Alexandre Julliard julliard@winehq.org wrote:
Reliably testing the foreground window is pretty hard, since the window manager is in charge of it. The user32 tests try, but despite their best efforts they still fail sometimes. So if you don't absolutely need that test, removing it is probably best.
It's kinda important in that if we don't have the right foreground window fullscreen D3D applications may not receive keyboard/mouse input. On the other hand, I don't necessarily need the test to remember.
-
Alexandre Julliard -
Henri Verbeet