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.