For smoother interaction of my application with the user I need to know when my program can see the whole flow of keyboard events from the user, and when this flow is interrupted. I’m testing my approach on a simple top-level with only a (subclassed) Rich Edit control inside. It turns out that checking for WM_KILLFOCUS and WM_SETFOCUS messages is not enough: these messages do not arrive when the text edit window wants to show menus. These menus “eat” the keypresses/keyreleases, but no “expected” message notifies me about this situation.
For the right-mouse-button menu I thought that monitoring WM_INITMENU, WM_INITMENUPOPUP, WM_UNINITMENUPOPUP, WM_ENTERMENULOOP, WM_EXITMENULOOP, WM_SYSCOMMAND, WM_COMMAND, WM_MENUCOMMAND, WM_MENUSELECT, WM_ACTIVATE, WM_ACTIVATEAPP, WM_MENUCHAR would give me “plenty of warnings” about what is going to happens. To my surprise, only WM_MENUCOMMAND (“marked as failure”) is received! Well, very strange — but I can live with it.
However, I cannot detect Alt-tapping (which moves the focus to “the icon for window’s menu” of the main window) at all: the next key-down event is (typically¹⁾) eaten, and no mentioned message arrives… For example, Alt-tap f gives key-down and key-up for Alt, but only key-up for f.
¹⁾ “Typical” since pressing appropriate keys (say, down-arrow) in this situation visualizes the “window’s menu”. However “a random key” would “cancel the focus stealing”. — However, the price is that one key-down event disappears.
So now my questions: the show-stopper for now is the detection of the focus moving to the icon for window’s menu. Can an application detect this moment? The second question is to understand why for the context menu (e.g., tapping on the Apps key) I do not get anything before the MENUCOMMAND event.
Finally: eventually, (if it works) I would prefer my code to be in a library — so it would need cohabitation with a multitude of ways.to “manage the window”. What I discussed above shows that (apparently) in Windows there is a way to steal focus without notifications. This means that there may be “other situations” — others than two types of menus discussed above — which would give the same kind of trouble to my code. So my third Question: is there a robust way to work around such situations? (And: how such situations are implemented via Windows APIs?!)