AutoHotkey Community

The problem with !ESC is that it produces side effects that appears to depend on environment in your script. May be hard od esay to workaround. I am losing my hear with FM problem easily...

_________________

Funny, I tried to isolate the problem but in this little script I don't lose focus to the menu when I click tray. That is, I lose focus only sometimes...

I notice how to reproduce focus lost with the sample below.
Click the tray icon, click the submenu, click anywhere aside (not the menu) to close the menu, click the tray again, the focus is lost.

Little difference doesn't remove the focus
Click the tray icon, click the submenu, ESC, click the tray.



Download sample here (with MMenu)

_________________

When I add this to the code above code, Sean, menu is closed:


I wonder how come the same code works with Notepad

The complete code:



2Sean
In test I uploaded MMenu_Show is changed so it calls TrackPopUpMenu with 0x180 flag.

_________________

More investgation:

MMenu stores handles to menus it created in array MMenu_aMenu[i] where i is i-th menu created.

so, I added this after creating menus:



and changed Activate func to:



And I get H different then any of MMenu menu handles.

Then, this


shows that when menu is visible, its parent is acctually active... (MMenu_hParent)

Then, this is strange. Shows 1 (proving my menu is the only windows with that class ATM )


I wonder why windows changes handle to the menu eachtime it is called for some small amount...


BTW, Menu losing focus is common problem around, not just in AHK. It has ben requested more then once and reported as bug, but this is defnitely not an AHK bug more like some weird WIn behavior...

_________________

In my test, it doesn't lose focus.


I think I found out why the menu is closed: AHK generates double ALT key presses. I noticed it through AHK's key history.
I don't know why AHK generates these ALT key presses atm.
Another mystery is why then these alt keys doesn't close the menu in notepad case.
Maybe timing issue? The Alt keys were generated before the menu got activated in notepad case?

I wonder why it generates ALT keys at all.... WinActivate does that. If you remove it, no keys are there.

This doesn't generate keys but doesn't work (also hides the menu):


I tried also directly to use menu handle created by MMenu with h := MMenu_aMenu[1], it doesn't help but doesnt' close the screen.

_________________

Perhaps Chris can tell us why WinActivate generates to ALTs

_________________

I had an error above I used SetForegrounWin instead SetActiveWin...




This kills the menu again, without having ALTs.

_________________

You can get some interesting results with this setup.

1. Go to MMenu_Show function and make menu parent inactive
Gui 77:Show, x0 y0 w100 h100 noactivate

This will pin the menu on screen once you call it via tray so it doesn't dissapear.

2. Set this code in Activate:


3. Open Winspector. Click the tray icon, menu is pinned and tooltip is shown. Drop the winspector (+) button on MMenu. Now when Winspector select it in the tree, RMB and say "Watch this windows class.." and watch its messages. After this, every time you run the script pop up with messasges will open in Winspector for that instance of class. So you can anaylise what is going on when activation message is sent.

Check out the winspector screen



17th message (selected one) is the last one when menu shows. Other messages are received after timer executed. Notice the toooltip and the winspector title.

After this you can return activation in MMenu_Show and see how things behave realtime. I am just monitoring.

The strange thing I notice is that in both cases, when menu has and doesn't has a focus, I have the same number of messages (17), first 17 above. None of them is connected to activation

_________________

This made me think...

If I do



I clearly got what I suppose to do.... WHAT THE HELL IS GOING ON.

_________________

This is the Winspector Properties report for Notepade case and MMenu case:



The only difference: WM_EX_LAYERED in MMenu (left is MMenu)


Found this at MSDN

To display a context menu for a notification icon, the current window must be the foreground window before the application calls TrackPopupMenu or TrackPopupMenuEx. Otherwise, the menu will not disappear when the user clicks outside of the menu or the window that created the menu (if it is visible). However, when the current window is the foreground window, the second time this menu is displayed, it displays and then immediately disappears. To correct this, you must force a task switch to the application that called TrackPopupMenu. This is done by posting a benign message to the window or thread, as shown in the following code sample:

SetForegroundWindow(hDlg);

// Display the menu
TrackPopupMenu( hSubMenu,
TPM_RIGHTBUTTON,
pt.x,
pt.y,
0,
hDlg,
NULL);

PostMessage(hDlg, WM_NULL, 0, 0);

_________________

Hum, this discussion is becoming too complex for me. Remember, I'm a beginner. I don't even know what is MMenu. Anyway, I want to keep my script as simple and light as possible.

I have tested again the !{ESC} trick, but I confirm that it doesn't work. Even the simple example I've posted in the last message of the previous page doesn't work with Always On Top windows.
It is easy to verify that. Open two windows. Make one of them Always On Top. Activate the normal window, and then the Always On Top one. Go to the script menu. The window identified as the active window after sending !{ESC} is the normal window. It should be the Always On Top one, as it was the last active window.

I have also tested the WM_ACTIVATEAPP trick, but no luck neither. I can't get it to retrieve the right window. But it's a good method to dynamically change the layout of the tray menu before showing it. Thanks for that.

_________________
r0lZ

Ah, I think I once read it long time ago while I was reading about why WM_NULL is called benign message...

Anyway, WinActivate or alike the menu turned out to be not a good idea, as it relys on unsupported behavior (with TPM_NONOTIFY).
Then, better monitor the AHK's trayicon message and store the active window:

Good idea! I'll try it.

_________________
r0lZ

2 r0lZ
!ESC works here with TOP windows. I tested with Favmenu which sets the folder in Open/Save after user invoked the menu with fav folders via tray. I opened Notepad Open/Save, made several windows on top and activated the OS. Favmenu set the folder correctly.

It seems that exact behavior depends on many factors which are script dependent.

BTW, MMenu is replacement for AHK Menu command. I made it, U have it in S&F forum with docs. I used it here as I can tweak internals of the Menu API to see what is going on when menu is activated/selected etc. U are confused with right. I had short PM about this with Sean and we continued here. Also this is unrelated to your problem, but in Favmenu, those 2 problems are connected. The problem is that MMenu sometimes loses focus - not just MMenu, but any Menu implementation (AHK Menu, 3th party menus etc...). This happens in FM3 when I do !ESC, hense connectivity. Without !ESC MMenu doesn't lose focus. THere were several questions related to "Menus losing keyboard focus" in previous year.


Well... we tried everything else I think.... I will wait for r0lz to see what is going on with this now. Thx for idea.

_________________