Add support for WM_COMMAND messages in order to handle HMENU user input on Windows

[fschutt]

Now that winit seems to have a with_hmenu function on Windows, it should be possible to handle WM_COMMAND messages. In Windows, menu items are associated with a unique ID (u32) and associates it with the HMENU. When the item is clicked, Windows will send a WM_COMMAND message to the window that owns the HMENU.

Back in 2018 I added menu support to winit here: fschutt@601d052

The fix would need to be ported to the current version, but it's very easy to understand. The relevant change would just be:

winuser::WM_COMMAND => {
    use events::WindowEvent::Command;
    send_event(Event::WindowEvent {
        window_id: SuperWindowId(WindowId(window)),
        event: Command(LOWORD(wparam as u32))
    });
    0
},

[maroider]

I'm not entirely happy with adding a Command variant to WindowEvent when it's unclear to me if any other OS would ever emit it in the future. Perhaps a callback-based approach like in #1759 would better serve the stop-gap-like nature of adding this immediately.

[msiglreith]

cc @madsmtm as they seem to work on sth in this direction. Would be interesting to know if it's strictly required to forward these commands or if it can be handled independently from winit using the HMENU handle only.

[madsmtm]

Haven't gotten far enough with the Windows implementation to tell if this is required or not, sorry!

[fschutt]

Okay, I've currently simply gone ahead and just backported the old fix to the newest winit version and added an example, since I need native menus in order to release azul. The patch is just 20 lines long and it works and I can't wait months and years until there is a common consensus on how to do it perfectly. So I'm just using a separate version as a dependency for azul now.

You can react to HMENUs on Windows without having to implement Command in winit itself: but the user has to subclass the window, has to watch that the subclass is running on the same thread as the window, etc. etc.

[maroider]

I have only looked at Windows' menu API briefly, but it does indeed seem like you can't get around handling the WM_COMMAND message. Like in #1878, subclassing is probably the only work-around for Winit not handling this directly, given the current API. This is far from ideal, as subclassing has some fun edge-cases (see #1798).

and I can't wait months and years until there is a common consensus on how to do it perfectly

I'd like to re-iterate that I think adding a platform-specific callback should be fine as a stop-gap measure until such consensus can be reached. A PR would be welcome.