Enhance the Options parameter of run()

[Feather]

1, add "Activate" parameter. Many processes don't activate after loading, they just keep blinking in the taskbar. I had to write a function like this instead of run()

Code: Select all

runshow(pt, dir?, opt?) {
	run(pt, dir?, opt?, &pid)
	if id := WinWait("ahk_pid " pid, , 1)
		WinShow(id), WinActivate(id)
}

2, I don't know which winapi is used by run(), I guess it is CreateProcess().

I am an ahk-h user and I use other software to load ahk.dll. When these dll threads call run() to create threads, it is very different from ahk.exe calling run() to create threads.
I can't set the CREATE_NEW_CONSOLE flag so that the new process doesn't create its own console, but takes over the current software's console.
My software uses a lot of worker processes, and the child processes exit as the parent process exits. I also can't use the work process related flags in run().

I would like Options to support the definition of the "CreateProcess()-dwCreationFlags" parameter, such as run(exe, dir, "max CREATE_NEW_CONSOLE")
or run(exe, dir, "max 0x00000010")

[lexikos]

they just keep blinking in the taskbar.

That is what happens when the process requests activation and the OS denies it.

I will not add an "activate" parameter, because this is not something that CreateProcess or ShellExecuteEx provide for. The only way it could be implemented is to search for and activate a window using exactly the same methods as a script would use. It isn't sensible to integrate the functionality of WinWait/WinActivate into Run. If you want to wait for and activate a window after launching the process, just do that by calling the appropriate functions. That way you can also specify which window to activate, when there are multiple.

Note: WinWait() sets the Last Found Window, so you can omit id. Unless DetectHiddenWindows is Off, WinWait will only find a window that is visible, so there's no need for WinShow. Perhaps you're turning DetectHiddenWindows On, but I would think that a hidden window belonging to the new process probably isn't designed to be forcibly shown by an external process.

I don't know which winapi is used by run(), I guess it is CreateProcess().

It uses CreateProcess if possible and falls back to ShellExecuteEx if needed. They do not share the same flags, so providing a simple numeric option for flags would probably not make sense.

CreateProcess is relatively trivial to call with DllCall if you merely need to specify flags like CREATE_NEW_CONSOLE.

I plan to eventually extend the functionality of Run to cover more of what CreateProcess can do, but it will likely not be any time soon.

When these dll threads call run() to create threads, it is very different from ahk.exe calling run() to create threads.

I have no idea what you mean. Run() simply launches an external process, and I would assume it does exactly the same in AutoHotkey_H.

[Feather]

OK, but let me remind you that we are defining run(), not its internal Winapi defining it.
Yes, the WinWait/WinActivate use doesn't seem appropriate at the bottom. I would prefer to use a window hook and then create a timer that destroys it. That way run() can return immediately.

If the dll thread belongs to a job process, then the process created by its run() automatically belongs to the job process as well. When the process to which the dll belongs exits, those created processes are also destroyed. It is very difficult for normal AutoHotkey.exe users to encounter this situation.

Thanks for your reply.

[lexikos]

OK, but let me remind you that we are defining run(), not its internal Winapi defining it.

I hadn't realized.

Run launches a document, URL or program. It does not and should not wait for and activate windows. It does not and should not asynchronously monitor for and activate windows. If the Win API had a flag that said "allow the new process to activate its window" or "force the first window of the new process to be activated", then it would be suitable to expose that with a Run option. It does not, and integrating the functionality of WinActivate into Run is not appropriate. The program provides you with functions to that you can call them when needed.

Yes, the WinWait/WinActivate use doesn't seem appropriate at the bottom.

Yes? That's basically the opposite of what I was saying. You want the script to activate the window once it appears, and it will appear soon but not immediately. WinWait/WinActivate is the simplest solution, and therefore likely the best.

There is even less chance that Run would have some built-in capability of detecting a new window after Run returns and activating it.