Script execution is stopped when menu is open

[swq]

When opened, script menu (right click on tray icon) seems to halt script execution. Hotkeys's presses aren't registered and MsgBoxes aren't shown until the menu is closed, though Sleep counters works so I think only the main thread is freezed. Is it a desired behavior? If so, can it be bypassed?

This question leads to the second one: Can the script menu be modified while it's open? As an example let's consider situation like this: one opens the menu and one option is disabled. After let's say 3 seconds it's enabled and it's ready to be clicked without reopening that menu. Can it even be done?

[mikeyww]

My general understanding is that yes, indeed, under Microsoft Windows, scripts pause while their menus are open. You can be the judge about whether that is desired!

[swq]

@mikeyww That's weird. Is it because winapi is so old that when it was forged everyone thought running everything in one thread and having UI blocking program execution was an OK thing to have? Or maybe it was done for performance reasons? Anyway thanks for your reply. Now I have to think of another way to achieve my goal.

[teadrinker]

Try this:

Code: Select all

Menu, MyMenu, Add, Item 1, Label
Menu, MyMenu, Disable, Item 1
Menu, MyMenu, Add, Item 2, Label
DllCall("SetTimer", "Ptr", A_ScriptHwnd, "Ptr", id := 1, "UInt", 2000, "Ptr", RegisterCallback("MyTimer", "F"))
Menu, MyMenu, Show
Return

Label() {
   MsgBox, % A_ThisMenuItem
}

MyTimer() {
   DllCall("KillTimer", "Ptr", A_ScriptHwnd, "Ptr", id := 1)
   Menu, MyMenu, Enable , Item 1
   Menu, MyMenu, Disable, Item 2
}

[mikeyww]

That is pretty cool!

[swq]

@teadrinker Thanks! I need to test this out but I think I can make use of this
Also I would appreciate if you or @mikeyww can share some resources in regard to this blocking behavior. I can't find anything about this phenomena though I'm probably asking google the wrong questions.

[mikeyww]

From @Chris:

When a script displays one of its own menus, it calls the OS function TrackPopupMenuEx(), which doesn't "return" until the user selects a menu item or cancels the menu. However, I believe TrackPopupMenuEx() does pump messages, which will allow future support for an option that allows hotkeys, timers, and other new threads to launch even though the script is displaying a menu. The problem with launching new threads is that if they don't finish promptly, TrackPopupMenuEx is left abandoned by the CPU, which causes the menu to become unresponsive until the thread finishes.

https://www.autohotkey.com/board/topic/8331-script-stops-when-context-menu-is-displayed/

[teadrinker]

I found one place where it's told in the docs:

... if the script is absolutely uninterruptible -- such as while a menu is displayed ...

[swq]

@teadrinker Could you explain to me why calling DLL works in this situation? I always thought that Sleep and SetTimer in AHK creates a new pseudo-thread and I think I was right since the timers keep count down time in the background, yet, if we have open menu, the callback is being called only when we explicitly use DllCall function. Does AHK internally handles timers in some custom way? SetTimer's priority doesn't seem to make any difference in this situation. It can't be just a nice user-friendly wrapper around this API because the effect isn't the same. The code you posted works perfectly fine but my confusion irritates me a lot and now I desperately need answers.

I also tested out a few programs on my computer and none of them freezes it's execution when I open its tray-icon-menu-thing which makes it even more puzzling for me. Maybe it's a well known behavior and developers smartly bypass this problem?

[teadrinker]

Could you explain to me why calling DLL works in this situation?

Unfortunately, I don't know much about how AHK works with timers. I tried my approach and saw that it works. I think @lexikos could clarify this better.

[swq]

Could you explain to me why calling DLL works in this situation?

Unfortunately, I don't know much about how AHK works with timers. I tried my approach and saw that it works. I think @lexikos could clarify this better.

It's ok. Thanks again for all your help!

[lexikos]

viewtopic.php?p=91639#p91639

[swq]

@Lexicos I appreciate your answer. I won't be lying that I understood much from that post but it doesn't seem to answer my question which is why teadrinker's solution with creating timer with DLL call works but it doesn't if the DllCall function is replaced with SetTimer command?

[lexikos]

https://www.autohotkey.com/docs/misc/Threads.htm#Interrupt

A thread can be uninterruptible for a number of reasons, including:
...
One of the script's menus is being displayed (such as the tray icon menu or a menu bar).
...
Any thread may be interrupted in emergencies. Emergencies consist of: ... 3) any callback indirectly triggered by the thread itself (e.g. via SendMessage or DllCall).

[swq]

https://www.autohotkey.com/docs/misc/Threads.htm#Interrupt

A thread can be uninterruptible for a number of reasons, including:
...
One of the script's menus is being displayed (such as the tray icon menu or a menu bar).
...
Any thread may be interrupted in emergencies. Emergencies consist of: ... 3) any callback indirectly triggered by the thread itself (e.g. via SendMessage or DllCall).

Thanks.