AutoHotkey Community

Thanks for the explanation.

BTW, I've had a look at MMenu yesterday. Very impressive, but as I have said, I don't want to use external libraries for my program, as it has to stay resident, and must therefore be as light as possible. But I will certainly use it later, for normal applications.

Note that I have used the extremely simple script I've posted above to test the !{ESC} key, and it works NEVER when the Always Top window is selected.
I have also changed the Always on Top mode with several methods (including with PowerMenu), still without luck.
I have even restarted my PC in safe mode. Still the same result.

IMO, the normal behaviour of !{ESC} is to send the first window that is NOT Alwaus on Top to the bottom of the stack. Obviously, it's normal, as sending an Always on Top window to the bottom doesn't make sense.

_________________
r0lZ

MMenu is very light, its consumption is next to nothing if menu is not very dynamic.


Try Favmenu from here and see for yourself

_________________

@r0lZ: Is it working for you? I think I have a solution that might be an overkill!

Interested

I haven't tried it yet. Sorry, but I haven't much time for now. I am involved in another project, much more important for me and others.

IMO, the difficulty is that there are a lot of WM_MOUSEMOVE messages, and I need to save the active window ID only once, when the mouse pointer arrives over the tray icon. I will investigate, probably today, and report here later...

_________________
r0lZ

OK, I've made some tests.

The only message that can be useful is WM_MOUSEMOVE (LParam = 0x200) as the app has not the focus yet when it receives the first messages.
However, it is difficult to use that message, as the same message is received again and again whenever the mouse moves over the tray icon, including when the tray has been activated by a click (of any button) and the window of interest has lost the focus.

Of course, I can check if the tray is active, and record the ID of the active window only when it's not the case, but since I have no way to know if it's the first message, it's indeed an overkill. However, I think that this method is better than the timer method, as it consumes CPU power only when the mouse pointer is over the icon.

But it's not the ideal method. Do you know a way to filter easily those messages to process only the first one that is received when the mouse arrives over the tray icon? Or is it a specific message to check that situation, or when the mouse goes away of the icon?

_________________
r0lZ

Dear r0lZ,



Run the code. And while target window has the focus double-click on the tray icon of this script.

For more info: http://www.autohotkey.com/forum/viewtop ... 323#123323

This doesn't work correctly. I will see to find out the reason but your shell spy showed me some UNKNOW message is received when window is activated.

With this, I get no msgbox



However, doubleclick on tray did work but only 1 window was affected.

Anyway, this method works only if Explorer is shell... not some serious limitation though...

_________________

Very nice, Skan!

Currently, I use the WM_MOUSEMOVE message, and it works nicely, but as I said in my previous post, the script receives many messages, and I haven't found a way to process only the first one. Your method is much more elegant, and ShellMessage() is called only when needed.

Thanks for the tip!

_________________
r0lZ

What's the problem?

_________________
r0lZ

I had guessed it would be so..

@r0lZ:

I forgot to mention.

Whenever Shell_TrayWnd, Progman or the GUI that is receiving the Shell Messages is activated ,the lParam will be 0x0.
This is actually convenient for most of the situations and that is why I am using the WinExist():
If ( wParam = 4 And WinExist( "ahk_id " lParam ) )

Thanks for the precision. It's exactly what I need. Pure magic!

BTW, using the MOUSEMOVE message method, I have still a problem. I suppose that your method will not magically resolve this issue.

I need to know if the currently active window is a "standard window". In other words, I need to exclude several windows, such as the traytips and tooltips, the menu windows, some invisible windows that I got sometimes (such as SysShadow) and in general all dialogs opened by (and usually on top of) another window. I guess that a "normal window" appears always in the Alt-Tab menu.
I don't know how to test that easily. I've tried to check the Style and ExStyle bits, but apparently no bits are either always set or clear for the windows of interest. Even the WS_TABSTOP style (0x1) is not sufficient to test that the window is "normal" and present in the Alt-Tab menu.

Any idea? How is it possible to check if a window is present in the Alt-Tab menu? Is it another method, or something that I have missed?

_________________
r0lZ

This might give you some idea: Alt-Tab replacement related- getting only alt-tab windows

Thanks for the tip. However, that doesn't work as expected.

I'm sure the method explained in the other thread works well for an Alt-Tab menu replacement, and it does exactly what I have asked, but unfortunately, it's not sufficient for me. I have to precise why.

The problem is that I need to know if the active window is what I call a "normal window", in other words the main window of an application, from the user point of view. The window of interest is the main GUI of the application.
The "normal window" should be the parent of all other windows of the application, and have no parent. However, for some applications (notably AlZip or MailWasher) the main "normal" window is not the window that sits in the taskbar and that is accessible via the Alt-Tab menu. The real root window of the application is invisible (although not hidden nor minimized) and is absolutely useless to the user. The normal window with the GUI is a child of that invisible window, and is therefore filtered by the function. If I manage to activate the invisible root window, it is correctly handled, but, of course, it's not what I want.

I suppose that the root, invisible window receives the Alt-Tab and activate/restore/minimize/maximize messages, and redirects them to the window with the GUI in some way.

Unfortunately, I think there is no way to handle this problem, as there are many tricks to hide a window, and I can't guess when I have to process it instead of, or in addition to the normal, visible and active window.

Thanks anyway.

_________________
r0lZ

I did the thing without tray icon Well, my app behaved the same when I was clicking the lil gui presenting 4th title button.

The easy thing to do here was to prevent activation of the window with WM_EX_NOACTIVATE. Then when you click the button, focus is returned imediately and you can get active win with WinExist("A").

Unfortunately you can't do this with tray icon.


I had banch of windows and EditPlus. I dblclk on tray icon, edit plus goes top. i do it again, it is not on top any more. I switch to Opera dblick tray icon, EditPlus goes top again, Opera isn't touched.

_________________

I know! I've tried.


Strange. In my case, everything works perfectly, although I have still the problem reported in my previous post, and a strange problem when I hide the active window with a Xbutton1 click on the tray icon. If I wait sufficiently to let the tray tooltip appear before clicking the tray icon, the tooltip is hidden instead of the window, and its shadow stays on the desktop, forever!
I don't know why it happens, as the tooltip should never receive the focus.
Also, seems this problem occurs only when the tooltip appears on top of the taskbar. (Seems there is a Windoze bug that makes it appear often below the taskbar.) I will try to disable the tooltip when I receive the HSHELL_WINDOWACTIVATED message, but I don't know yet how to re-enable it after.
I have the same problem with traytip messages, but it is easier to close them before, as I don't have to re-enable them.

_________________
r0lZ