AutoHotkey Community

[JBensimon]

Hello.

Can anybody suggest a reliable way within the AutoHotkey feature set of referring to a particular window (e.g. for the purpose of WinMinimize or WinClose) when its title and contents are subject to unpredictable change over time? The process to which the window belongs would originally have been launched by the AutoHotkey script itself via Run, so the process ID can be assumed to be available, but I don't see an obvious way to get from a process ID to the window that belongs to the process and from there to the window's current title/contents (which seem to be required by window management functions like WinMinimize). [We can assume that a single window is associated with the process, but a solution that acts upon all the windows belonging to the process would be great too].

Thanks,

Jacques.

[corrupt]

Maybe using WinGet

[JBensimon]

Thanks for the tip. Until I carefully read about WinGet (as a result of your reply), I hadn't realized that "ahk_id <windowID>" can be used as a reference to a window for purposes of WinMinimize, etc. This of course still leaves the problem of obtaining the window ID(s) belonging to the process of interest, but if I understand your suggestion, I should get a list of all windows on the system using WinGet and then, for each one, call WinGet again to get the name of its owning process and thus discover the window(s) of interest. Is this the most straightforward way to figure out which windows belong to a given process?

Thanks again.

Jacques.

[jonny]

Also, I believe an "ahk_pid" is in the making, which would solve your problem. It would eliminate the need to retrieve the title first when using Win commands.

[corrupt]

Here's an example:

[JBensimon]

The code I wound up using is similar but not quite identical to what you suggest (and thanks for the effort, by the way). The twist in my requirement is that at no point do I know enough about the launched window to obtain its ID directly via WinGet (because I am basically passed an unknown command line to Run), so what I had to do after launching the command (and capturing the resulting PID) was to enumerate *all* windows via WinGet (List option) and then loop through the resulting array of window IDs to find the one(s) with matching PID (using WinGet to obtaind the PID of each window's owning process and comparing it to my previously saved PID). This lets me identify the window ID(s) of the window(s) belonging to the launched process for use in window management function calls.

Two notes:

(1) The documentation of WinGet does not make it clear that the "ahk_id <windowID>" syntax may be used to obtain information on a window (such as its owning PID). Title/Text and ahk_class are mentioned in the WinGet doc, but not ahk_id (though it works just fine).

(2) Run is very finicky about when it does and doesn't provide a resulting PID. Is Run implemented using ShellExecuteEx, by any chance? I know that this call only returns a PID when an actual new process is launched (which for example isn't the case when a document is launched and opened by an already running process). Strangely, however, I have found that using Run with an explicit fully qualified path to an executable does return a PID, but using Run with just an executable name and relying on its presence in %PATH% (or other form of shell integration) does NOT return a usable PID. Is this normal, or should I report it elsewhere?

Thanks also to "jonny" for mentioning an (upcoming?) ahk_pid feature. Do I understand correctly that this will provide a way of referring to windows by the PID of their owning process? If that's the case, would WinMinimize, ahk_pid %ProcessID% act upon *all* the windows belonging to the specified process? [For that matter, how dows WinMinimize, ahk_class %ClassID% behave now when there are multiple windows of the specified class?]

Man, do I love AutoHotkey!

Jacques.

[jonny]

*laughs* I love the quotes around my handle.

I believe when multiple windows are found, it acts on the topmost one, but I'm not sure.

[Chris]

[JBensimon]

Chris,

Thanks for the (as always thorough) reply. I will test the full path / no path Run behavior again and report back if the PID results differ from what you describe.

Pretty amazing that a function to get a process ID from a handle to the process, which ShellExecuteEx does (sometimes!) return, has only recenly been added to the API. You'd think that would have been a natural from the word go.

Jacques.

PS: Love the new OutputDebug feature! Maybe you could provide a new directive to turn debugger output on/off (i.e. execute/ignore OutputDebug commands).

[JBensimon]

Chris,

You are quite right that executables in the system %PATH% are launchable via CreateProcess() and therefore do return a PID. The executables I had previously tested (like IExplore.exe and Excel.exe) are listed under the "App Paths" registry key and are therefore launchable (without being fully qualified) by the shell and via ShellExecute(), but not by CreateProcess(), so it stands to reason I was not getting a PIDback from the Run command.

Thanks again.

Jacques.

[Chris]

Thanks for the follow-up.

[JBensimon]

[jonny]

With DebugView you can filter the incoming messages, too, so there's no need to even quit it. And if you're worried about the performance drop, well then: 1) It's extremely small, hardly worth thinking about from any perspective. 2) Why would you be using a scripting language if you're so worried about infinitesimal performance drops?

Anyway... ya.

[Chris]