[1/5] user32: Notify the user driver of hotkey changes.

[Vincent Povirk]

I was told the last error handling in the previous version of this patch was "ugly". I'm not entirely sure this is better, but it demonstrates an alternative approach. This new approach looks simpler, but it packs a lot of assumptions in a small space.

There are two different ways a RegisterHotKey call can fail in the user driver:
 * The desired key combination is already grabbed, either by this process or another process.
 * The operation is unsupported (user driver does not know how to grab this key combination).

The user driver reports an unsupported operation as a success because we can always register the hotkey in the server. The hotkey will only work when a Wine window is active, but it's better than nothing.

There are also two different ways a RegisterHotKey call can fail in the server:
 * The window is invalid or belongs to some other thread.
 * The desired key combination is already registered, either by this process or another process.

We have to account for every possible combination of those circumstances.

If the user driver succeeds and really does grab the hotkey, then we already know that no other process has registered it (unless we're dealing with different processes on different displays, in which case things may be broken and I DO NOT CARE). The only possible failure then is an invalid window.

If the grab succeeds and the server call fails (which must be due to an invalid window), we need to tell the user driver to unregister the grab. Since this was a failing case, we need to preserve the last error, which is where the ugly last error handling came in.

The alternative approach is to anticipate the failure due to an invalid window and not forward the call to the user driver if the window is invalid. We still need the server call to tell us exactly WHY the window is invalid (whether it's a window in another thread or there is no such window), so we have to continue anyway.

I don't like this approach because it relies on these assumptions that are not obvious, and it seems fragile to me. If it's somehow possible for the user driver to successfully grab a key when the server thinks the key is grabbed by some other thread, we'll end up with a situation where the current thread is grabbing a key that is not a hotkey, and there will be no way to release the grab except to destroy the appropriate thread or window. If it's possible for WIN_IsCurrentThread to return FALSE for a window the server considers valid (could this happen for the desktop window?), we have a situation where RegisterHotKey claims to succeed but doesn't really grab the key. In neither of those cases do we see any indication that something went wrong.

Then again, I didn't much like the other approach either because we end up trying to grab a key that we may or may not ultimately want to keep.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20110623/83f73719/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-user32-Notify-the-user-driver-of-hotkey-changes.txt
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20110623/83f73719/attachment.txt>