AutoHotkey Community

1. If a custom menu is shown called by a mouse event, subsequent events should close the menu and the script should intercept the WM message. Now the script misses the message.

2. It would simplify scripts if menu names could be stored in variables and given to the Menu Show command.

In a script I defined many right-click menus, different ones for different edit boxes. If I don't select anything from a menu, but right click the same edit box again, the standard right-click menu pops up instead. Right-clicking again in the edit box pops up my custom menu, alternating between it and the standard menu. It is quite disturbing, but can be worked around with timers. Unfortunately, the Menu Show command does not accept the menu name in a variable, so for each menu in the script we need a different timer subroutine. Here is the working version.The simpler version of the RButtonDown function produces the alternating right-click menus.Below is the script, which causes a run time error.

I believe both of the above are caused by the following documented limitation of OnMessage: "If a monitored message that is numerically less than 0x312 arrives while the script is absolutely uninterruptible -- such as while a menu is displayed, a KeyDelay/MouseDelay is in progress, or the clipboard is being opened -- the message's function will not be called and the message will be treated as unmonitored."

However, I've lately been pondering whether the policy of forbidding hotkeys from launching while the script is displaying a menu should be changed. If it gets changed for hotkeys, it might get changed for OnMessage too.

It's already allowed. Just be sure to declare variables as global inside a function if some global subroutine needs to access them.

Damn! I keep forgetting about Global!

Then this limitation about messages less than 0x312 is not that bad. We only need 10 extra lines of AHK code. Chris, maybe you could add to the documentation a workaround, something like this:

I'm sure you're not the only one. Although the requirement for Global improves script maintainability, it's probably more draconian than it's worth. However, another reason it was done is that it simplified the code a lot.

In the future, there will probably be an ability to declare super-global variables by using the global keyword outside of any function. This would cause such variables to be global to all functions.

The explanation in my previous post was wrong. Instead, both of the behaviors are caused by the following documented limitation: "If a message arrives while its function is still running due to a previous arrival of the same message, the function will not be called again; instead, the message will be treated as unmonitored."

Since there are already some work-arounds for this described in the documentation, I probably won't add your example to it. However, in the future there may be a way to optionally allow more than one thread per OnMessage function.

I thought allowing more than one thread would open further copies of the custom menu, which is not what we want. An option would be nice, allowing subsequent occurrences of the same event to close the menu (terminate the running thread). I did read the documentation, but the suggested workarounds do not work in my system. This is why I posted originally a script. I tried adding Critical in the subroutine and Thread Interrupt,0,0 (also with many other pairs of parameters). Neither has any effect on the alternating standard/custom menus. Could anyone post a script, where the documented workarounds prevent the alternating menus?

You're right, that's caused by the following: "A message less than 0x312 cannot be buffered by Critical or Thread Interrupt; the only way to guarantee that no such messages are missed is to ensure the function finishes in under 10 milliseconds. One way to do this is to have it queue up a future thread by posting to its own script a monitored message number higher than 0x312. That message's function should use Critical as its first line to ensure that its messages are buffered."

I think the above used to mention your SetTimer method as a workaround, but then someone mentioned the idea above as superior so I changed it. Since the documentation for OnMessage is already dauntingly long, it seems best to devote only a small amount of space to obscure issues.

For me this is not an obscure issue. Right-click menus are very common, and popping up the wrong one every other time makes our scripts look amateurish or buggy. I try to use AHK in my work, writing small applications, but they must look professional to be accepted.

In any case, with Chris' hints, I could come up with a script which uses the documented workarounds. I post it here, so anyone can find it, who has similar problems. Having many GUI controls this technique makes the script longer, but more reliable, as the timer method (very rarely) still pops up the wrong menu.

I meant no offense, only that the preferred method of doing right-click menus is GuiContextMenu. I realize that you can't use that in this case because you're overriding an Edit control's built-in context menu.

Thanks for posting your final solution.

I could not make it work in my system. Try the following script. As I understood the documentation, at right click in the edit box the MsgBox should pop up. It does not. Only at a right click in the empty area inside the GUI window triggers the GuiContextMenu subroutine. Double clicks are not caught anywhere, so I could not find other ways to react to mouse clicks, but the OnMessage method above. Did I do something stupid like in my original post omitting the Global directive?

Below is a demonstation of another method to introduce custom context menus in AHk GUI windows. Some notable features:

* preserves full RButton functionality in unspecified windows (i.e., contexts)
* enables coexistance of default and custom menu. default menu is shown when RButton is depressed and released in a time less than threshold and, if depressed longer, will show the custom menu. the idea for this dual existance was demonstrated by Decarlo110.

Thanks, Shimanov! This approach, monitoring the state of the right mouse button and doing special actions when the cursor is over designated areas (and keys are pressed for a long time), could be made to work. I think the following script is functionally equivalent, but shorter and more robust (the original freezes if I right click on the title bar).However, both suffer from the same problem: If a right-click pops up a menu (custom or standard), subsequent right-clicks anywhere in the same GUI are not registered by AHK, until another mouse button is pressed or the active window is changed. Looks like an AHK bug or something is weird with my PC. Problems like this and the one with GuiContextMenu made me switch to the OnMessage method. Could you check that the problematic cases work in your PC?

An Edit control's context menu takes precedence by design (and this is documented). You might notice earlier that I said, "I realize that you can't use [GuiContextMenu] in this case because you're overriding an Edit control's built-in context menu."

Not quite. It doesn't support right button drag and drop.



I have confirmed this behavior. It is likely a bug with AHk. I have modified AHk to resolve this issue. You can try a preview of this revised version here and the revised source.



Also confirmed. Try the following revised code:

(It seems to catch every right click [to your heart's content].)

I realized that. This is why my post is not in Bug Reports, but a wish: could it be changed?

Shimanov, your changes in AHK and your last script seems to work. However, my version (with right-drag) still does not. (Needs a left-click or key press before the custom menu starts working again.) Is there a problem in there?