 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
 Posted: Fri May 18, 2007 9:14 am Post subject: |
 |
|
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...
_________________
 |
|
| Back to top |
|
 |
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 9:31 am Post subject: |
|
|
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.
| Code: | CoordMode, Mouse, Screen
#SingleInstance, force
Menu, Tray, Add, Show Menu, TrayDefault
Menu, Tray, Default, Show Menu
Menu, Tray, Click, 1
menu := MMenu_Create()
menu2 := MMenu_Create()
loop, 10 {
MMenu_add(menu, "item" A_Index, "Shell32.dll:" A_Index)
MMenu_add(menu2, "item" A_Index, "Shell32.dll:" A_Index+60)
}
MMenu_Add(menu, "menu2", "Shell32.dll:20", "", "m" menu2)
return
Handler:
return
TrayDefault:
MouseGetPos, x, y
MMenu_Show(menu, x, y, "Handler")
return
|
Download sample here (with MMenu)
_________________
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 9:36 am Post subject: |
|
|
When I add this to the code above code, Sean, menu is closed:
| Code: | DetectHiddenWindows, on
...
TrayDefault:
SetTimer, Activate, 500
MouseGetPos, x, y
MMenu_Show(menu, x, y, "Handler")
return
Activate:
SetTimer, Activate, off
WinActivate, ahk_class #32768
return
|
I wonder how come the same code works with Notepad
The complete code:
| Code: | DetectHiddenWindows, on
CoordMode, Mouse, Screen
#SingleInstance, force
Menu, Tray, Add, Show Menu, TrayDefault
Menu, Tray, Default, Show Menu
Menu, Tray, Click, 1
menu := MMenu_Create()
menu2 := MMenu_Create()
loop, 10 {
MMenu_add(menu, "item" A_Index, "Shell32.dll:" A_Index)
MMenu_add(menu2, "item" A_Index, "Shell32.dll:" A_Index+60)
}
MMenu_Add(menu, "menu2", "Shell32.dll:20", "", "m" menu2)
return
Handler:
return
TrayDefault:
SetTimer, Activate, 500
MouseGetPos, x, y
MMenu_Show(menu, x, y, "Handler")
return
Activate:
SetTimer, Activate, off
WinActivate, ahk_class #32768
return
#include includes
#include MMenu.ahk
#include structs.ahk
|
2Sean
In test I uploaded MMenu_Show is changed so it calls TrackPopUpMenu with 0x180 flag.
_________________
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 10:11 am Post subject: |
|
|
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:
| Code: | hMenu := MMenu_aMenu[1] + 0
hMenu2 := MMenu_aMenu[2] + 0 |
and changed Activate func to:
| Code: | Activate:
SetTimer, Activate, off
h := WinExist("ahk_class #32768")
msgbox HMenu:%hMenu%`nHMenu2: %hMenu2%`n H:%h%
return |
And I get H different then any of MMenu menu handles.
Then, this
| Code: | Activate:
SetTimer, Activate, off
h := WinExist("A")
WinGetClass, class, ahk_id %h%
msgbox HMenu:%hMenu%`nHMenu2: %hMenu2%`n H:%h%, %class%
return |
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 )
| Code: | Activate:
SetTimer, Activate, off
WinGet, out, list, ahk_class #32768
msgbox %out%
return |
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...
_________________
|
|
| Back to top |
|
|
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Fri May 18, 2007 12:20 pm Post subject: |
|
|
| majkinetor wrote: | 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. |
In my test, it doesn't lose focus.
| Quote: | | When I add this to the code above code, Sean, menu is closed: |
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? |
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 1:34 pm Post subject: |
|
|
| Quote: | 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. |
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):
| Code: | Activate:
SetTimer, Activate, off
h := WinExist("ahk_class #32768")
DllCall("SetForegroundWindow", "uint", h)
return
|
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.
_________________
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 1:55 pm Post subject: |
|
|
Perhaps Chris can tell us why WinActivate generates to ALTs
_________________
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 2:10 pm Post subject: |
|
|
I had an error above I used SetForegrounWin instead SetActiveWin...
| Code: | Activate:
SetTimer, Activate, off
h := WinExist("ahk_class #32768")
DllCall("SetActiveWindow", "uint", h)
return |
This kills the menu again, without having ALTs.
_________________
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 2:33 pm Post subject: |
|
|
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:
| Code: | Activate:
SetTimer, Activate, off
h := WinExist("ahk_class #32768")
DllCall("SetActiveWindow", "uint", h)
tooltip %h% %Menu_aMenu[1]% ;current handle, creation menu handle
return |
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
_________________
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 2:44 pm Post subject: |
|
|
This made me think...
If I do
| Quote: | Activate:
SetTimer, Activate, off
WINMOVE, ahk_class #32768, , 0, 0
return |
I clearly got what I suppose to do.... WHAT THE HELL IS GOING ON.
_________________
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Fri May 18, 2007 2:54 pm Post subject: |
|
|
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);
_________________
|
|
| Back to top |
|
|
r0lZ
Joined: 21 Apr 2007
Posts: 177
|
| Posted: Fri May 18, 2007 10:02 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Fri May 18, 2007 11:08 pm Post subject: |
|
|
| majkinetor wrote: | | 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: |
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:
| Code: | | MsgID: 1028, wParam: 1028, lParam: 0x200 ~ 0x209 (WM_MOUSEMOVE ~ WM_MBUTTONDBLCLK) |
|
|
| Back to top |
|
|
r0lZ
Joined: 21 Apr 2007
Posts: 177
|
| Posted: Fri May 18, 2007 11:29 pm Post subject: |
|
|
| Sean wrote: | Then, better monitor the AHK's trayicon message and store the active window:
| Code: | | MsgID: 1028, wParam: 1028, lParam: 0x200 ~ 0x209 (WM_MOUSEMOVE ~ WM_MBUTTONDBLCLK) |
|
Good idea! I'll try it.
_________________
r0lZ |
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Sat May 19, 2007 10:28 am Post subject: |
|
|
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.
| Sean wrote: | | Then, better monitor the AHK's trayicon message and store the active window: |
Well... we tried everything else I think.... I will wait for r0lz to see what is going on with this now. Thx for idea.
_________________
|
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
