Wine test day #2: an easy lob

[Jeremy White]

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

[Piotr Caban]

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

Wine test day #2: an easy lob

[Henri Verbeet]

On 6 March 2014 19:38, Piotr Caban  wrote:
> 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.

Is this caused by a specific ddraw test?

Wine test day #2: an easy lob

[Piotr Caban]

On 3/6/14 7:55 PM, Henri Verbeet wrote:
> On 6 March 2014 19:38, Piotr Caban  wrote:
> > 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.
>
> Is this caused by a specific ddraw test?

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.