[PATCH v8 1/5] wmp: Add OPEN/PLAY state change notifications

[Anton Romanov]

On Fri, Apr 6, 2018 at 10:28 AM, Jacek Caban <jacek at codeweavers.com> wrote:
> Hi Anton,
>
> Note that we'll need to store states in WMP object at some point, at
> least so that we can implement get_openState() and get_playState(), but
> I'm fine with the patch for now. Please just address one comment bellow.
We probably will eventually. For now I was implementing the bare
minimum my test game needs.
And adding saving of states would be a fairly easy change as all state
updates now go through the same function anyway.
(And frankly, only because it crashes with native WMP)

> On 04/03/2018 07:36 AM, Anton Romanov wrote:
>>      ok(hres == S_OK, "IWMPControls_play failed: %08x\n", hres);
>> +    {
>> +        MSG msg;
>> +        DWORD start_time = GetTickCount();
>> +        DWORD dwTimeout = 5000;
>> +        HANDLE handles[1];
>> +        handles[0] = playing_event;
>> +        do {
>> +            DWORD now = GetTickCount();
>> +            res = MsgWaitForMultipleObjectsEx(1, handles, start_time + dwTimeout - now,
>> +                    QS_ALLINPUT ,MWMO_ALERTABLE | MWMO_INPUTAVAILABLE);
>> +            if (res == WAIT_OBJECT_0 + 1) {
>> +                GetMessageW(&msg, 0, 0, 0);
>> +                if (winetest_debug > 1)
>> +                    trace("Dispatching %d\n", msg.message);
>> +                TranslateMessage(&msg);
>> +                DispatchMessageW(&msg);
>> +            }
>> +        }
>
>
> In general, adding a new block purely for variable declarations is not
> encouraged. In this case, I'd suggest a helper pump_messages() function
> here.
Sure, will do. I left it inline initially only because there was just
one occurence of it.
Now that I use it for both completion and playing events it makes even
more sense to factor it out.

>
> Thanks,
>
> Jacek
>