[PATCH] user32: Handle WM_SYSKEYDOWN in MENU_SuspendPopup.

[Alex Henrie]

2016-11-09 12:26 GMT-07:00 Alexandre Julliard <julliard at winehq.org>:
> Alex Henrie <alexhenrie24 at gmail.com> writes:
>
>> Technically, all the stuff about WM_SYSKEYDOWN is unnecessary. All we
>> really need to do is fix the error handling, or remove this questionable
>> optimization altogether.
>
> I'm not sure what you mean by that. Also you are essentially reverting
> d75b0cdc986f464f3067767cd53aca6b85feb366, I'd like to hear some
> justification for that.

The goal is to fix https://bugs.winehq.org/show_bug.cgi?id=41508

Currently, when MENU_TrackMenu gets WM_SYSKEYDOWN with wParam=VK_LEFT,
it calls MENU_KeyLeft, which calls MENU_SuspendPopup. The problem is
that MENU_SuspendPopup does not remove the message, and it sets
TF_SKIPREMOVE so that MENU_TrackMenu does not remove it either. So,
the message stays in the queue and MENU_TrackMenu is called all over
again.

Instead of adding WM_SYSKEYDOWN to the switch statement, we could fix
the bug in one line by moving "pmt->trackFlags |= TF_SKIPREMOVE;" into
the WM_KEYDOWN case. Or, we could delete MENU_SuspendPopup entirely
and the if statements that call it. However, we wouldn't be setting
TF_SKIPREMOVE anymore for unrecognized messages, likely causing a
return of the bug that d75b0cdc tried to fix.

By the way, I'm not exactly reverting d75b0cdc. I changed PM_REMOVE to
PM_NOREMOVE to make sure that messages are removed only if they are
recognized.

I hope that makes sense; I admit that my previous explanation was not
as well thought out as it could have been. Thanks for the feedback.

-Alex