So it looks like the easy test for the day is drag/drop: http://test.winehq.org/data/tests/ole32:dragdrop.html
Evidence suggests both that Piotr broke it, but is also working to fix it, so I don't think I get to shame him publicly...yet <grin>.
Cheers,
Jeremy
I'm still trying to find what's happening there. It's related to some strange state that ddraw and dinput8 tests leaves mouse in.
What happens if dragdrop tests are executed just after dinput8 tests (and mouse is left above desktop): - dinput8 simulates mouse left button being pressed - this starts marquee selection on desktop (that is still in progress during dragdrop tests) - dragdrop is not receiving any mouse messages so it hangs (only desktop window is receiving mouse messages) I've tried adding a temporary window that receives the click. This lets this tests run successfully.
Unfortunately it doesn't work when ddraw tests are also executed. If so dinput8 still causes mouse messages to be not delivered. It's somehow related to windows still doing some work related to recent mode changes. This case starts working if I add a 1 second sleep after ddraw tests. I don't know what really happens here.
I'm attaching a work in progress patch for dinput8 tests. I'm slowly out of ideas how to proceed further. If anyone has any thoughts please let me know.
Thanks, Piotr
On 6 March 2014 19:38, Piotr Caban piotr.caban@gmail.com wrote:
Is this caused by a specific ddraw test?
On 3/6/14 7:55 PM, Henri Verbeet wrote:
I don't think it's actually related to ddraw tests. It's probably exposing some kind of race inside dinput8 tests. I was testing it with all tests disabled except ddrawmodes.