qwerty12 wrote:INTERRUPTIBLE_IN_EMERGENCY checks to see if a menu is being displayed at that point, which what lifeweaver was demonstrating. I won't embarrass myself by pretending to understand why it's there - ...
The reasons aren't very clear, but the main one in this case is:
Launching a new thread while a menu is visible "would produce strange effects because any timed subroutine that took a long time to run might keep us away from the "menu loop", which would result in the menu becoming temporarily unresponsive while the user is in it (and probably other undesired effects)."
There are other reasons for g_MenuIsVisible (which is usually set by the WM_ENTERMENULOOP handler and Menu command):
AutoHotkey implements "buffering" of messages when the thread is uninterruptible (e.g. Critical) by filtering which messages it retrieves from the message queue. If some code outside our control (e.g. TrackPopupMenu) is running a message loop, this filtering doesn't happen and the message is immediately dispatched to the window procedure. There are two ways that such messages can be handled:
- Drop the message.
- Re-post the message to the message queue.
If the message is re-posted but there's a message loop running outside our control, the message will just be dispatched back to the window procedure. This can cause a loop which can lock up the GUI or otherwise hurt performance. The comments in the source code describe it as a "bouncing effect":
"v1.0.36.03: The g_MenuIsVisible check was added as a means to discard the message. Otherwise MSG_FILTER_MAX would result in a bouncing effect or something else that disrupts a popup menu, namely a context menu shown by an AltSubmit ListView (regardless of whether it's shown by GuiContextMenu or in response to a RightClick event)."
The mouse hook uses g_MenuIsVisible as a shortcut for detecting menus, for correct handling of mouse buttons in some specific cases. However, if g_MenuIsVisible is false it will double-check by searching for a menu window anyway.
The keyboard hook uses g_MenuIsVisible when collecting input to pass the correct flags to ToUnicodeEx/ToAsciiEx. I'm not sure what effect the flag has.
g_MenuIsVisible is set by the WM_ENTERMENULOOP handler and the Menu command. Therefore, if you block the message and
bypass the Menu command, AutoHotkey won't know there's a menu open, so the safety measures and other things that rely on detecting menus won't work, but you'll be able to launch new threads.
wz520 wrote:I know this. The point is: I want to do these things when a menu is about to be shown.
You want to do things the difficult and risky way?
Why?
Since you were directly showing the menu yourself, it would have made a lot more sense to just make your changes to the menu
before showing it.