AutoHotkey Community

[r0lZ]

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

[majkinetor]

[SKAN]

[r0lZ]

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

[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

[SKAN]

Dear r0lZ,

[majkinetor]

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

[r0lZ]

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

[r0lZ]

[SKAN]

[r0lZ]

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

[SKAN]

[r0lZ]

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

[majkinetor]

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.

[r0lZ]