2016-11-09 12:26 GMT-07:00 Alexandre Julliard julliard@winehq.org:
Alex Henrie alexhenrie24@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