Hi!
A general question:
There seems to be situations where a running AHK script (compiled) is not shown in Task Manager.
Is this a known issue? What is the reason, what can be done to prevent this behavior?
EDIT:
This was my first observation. In the meantime I know in which situations this problem occurs. See below.
An unsatisfactory behavior of the Run command? Topic is solved
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
An unsatisfactory behavior of the Run command?
Last edited by newbieforever on 03 Sep 2018, 08:38, edited 2 times in total.
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: An unsatisfactory behavior of the Run command?
This problem occurs if a (compiled) AHK script is run from another AHK script.
Demonstration:
Running_TM.ahk:
StartScript.ahk:
If Running_TM.exe is run e.g. from Explorer, it is shown in TM (under Backgroud Processes or, after displaying the MsgBox by ^!+t, under Apps).
However, if Running_TM.exe is run by StartScript.ahk, this logical and consistent behavior is broken: It is shown as a subentry of AutoHotkey! After displaying the MsgBox, this subentry disappears and an own entry for Running_TM.exe is shown under Apps.
I suppose, as usualy in such cases, many of other users will consider this behavior to be logical and consistent from other points of view (related to the nature of AutoHotkey), or not to be of relevance. For me (especially in the context of my project) this behavior is extremely unsatisfactory.
My concrete question:
Can this problem be avoided? How to run a (compiled) AHK script from another AHK script without having this problem?
EDIT
PS: I alredy know that this problem doesn't occur if the script contains an element leading to a permanent taskbar button. But this is not a solution if the script shouldn't have a taskbar button...
Demonstration:
Running_TM.ahk:
Code: Select all
#SingleInstance, Force
#Persistent
#NoTrayIcon
RETURN
^!+t::
MsgBox SCRIPT IS RUNNING!
Return
Code: Select all
Run %A_ScriptDir%\Running_TM.exe
;Run %comspec% /k "%A_ScriptDir%\Running_TM.exe", , Hide
Gui StartGui: Show, x0 y0 w100 h100
However, if Running_TM.exe is run by StartScript.ahk, this logical and consistent behavior is broken: It is shown as a subentry of AutoHotkey! After displaying the MsgBox, this subentry disappears and an own entry for Running_TM.exe is shown under Apps.
I suppose, as usualy in such cases, many of other users will consider this behavior to be logical and consistent from other points of view (related to the nature of AutoHotkey), or not to be of relevance. For me (especially in the context of my project) this behavior is extremely unsatisfactory.
My concrete question:
Can this problem be avoided? How to run a (compiled) AHK script from another AHK script without having this problem?
EDIT
PS: I alredy know that this problem doesn't occur if the script contains an element leading to a permanent taskbar button. But this is not a solution if the script shouldn't have a taskbar button...
Re: An unsatisfactory behavior of the Run command? Topic is solved
ShellRun would probably work around it. Search the forum or installer.ahk (in the AutoHotkey installation directory) for it.
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: An unsatisfactory behavior of the Run command?
As usual: a precise, concise, accurate and effective answer by lexikos. ShellRun works.lexikos wrote:ShellRun would probably work around it.
Btw: "For me ... this behavior is extremely unsatisfactory." Is this my view not reasoned and legitime? Would not it be better to have a Run command version in AHK that does not have this "flaw"?
Re: An unsatisfactory behavior of the Run command?
This is not a flaw in the Run command. How other programs choose to group processes is outside the purview of the Run command.
The Run command uses CreateProcess and ShellExecute to launch processes, the same as virtually every other Windows program ever. I believe the only user-mode alternative to these two functions is to get some other process to do it for you, and that's what ShellRun does (the other process is explorer.exe). Ultimately CreateProcess or ShellExecute is used to launch the process, so it's just a case of who launches it.
Task Manager presumably groups them because background processes are assumed to be part of the same "application" as the parent process. I am not aware of any API that affects the grouping, but if one was added for this specific purpose, Task Manager could not rely on the information being available since grouping by application is a recent invention.
Windows 7 and up have the concept of an "application user model ID" which affects grouping of taskbar buttons, but this has no effect on Task Manager.
The Run command uses CreateProcess and ShellExecute to launch processes, the same as virtually every other Windows program ever. I believe the only user-mode alternative to these two functions is to get some other process to do it for you, and that's what ShellRun does (the other process is explorer.exe). Ultimately CreateProcess or ShellExecute is used to launch the process, so it's just a case of who launches it.
Task Manager presumably groups them because background processes are assumed to be part of the same "application" as the parent process. I am not aware of any API that affects the grouping, but if one was added for this specific purpose, Task Manager could not rely on the information being available since grouping by application is a recent invention.
Windows 7 and up have the concept of an "application user model ID" which affects grouping of taskbar buttons, but this has no effect on Task Manager.
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: An unsatisfactory behavior of the Run command?
Lexikos, you are absolutely right in all the details, of course. But I have the feeling that your answer ignores a small more fundamental aspect. If AHK behaves differently in one point on Windows than other programs, it would be useless to say that Windows (or one of its components, a feature) is to blame; Windows is the eternal basis that will never adapt to AHK, it can only be the other way round. So, if an AHK program, when started from another AHK program, behaves differently in certain constellations than if it had been started in some other way: emotionally we can pass the buck to Windows, but seriously (= pragmatically) only AHK can be held responsible. So should we not call such a (unfavorable) behavior, if not as a flaw, at least as a "flaw" (or a "blemish", or "________" [please fill in the blanks]) of AHK?lexikos wrote:This is not a flaw in the Run command. How other programs choose to group processes is outside the purview of the Run command.
Last edited by newbieforever on 08 Sep 2018, 09:40, edited 3 times in total.
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: An unsatisfactory behavior of the Run command?
Another possible workaround might be this:
The problem described (an active AHK program does not appear in the Task Manager) only occurs when an AHK program that does not have a permanent gui is started from another AHK program. So an invisible permanent gui not having a taskbar button would potentially be a solution.
The hint how to do that came (of course) from lexikos.
A demo script:
The problem described (an active AHK program does not appear in the Task Manager) only occurs when an AHK program that does not have a permanent gui is started from another AHK program. So an invisible permanent gui not having a taskbar button would potentially be a solution.
The hint how to do that came (of course) from lexikos.
Code: Select all
ITaskbarList(winId, n) {
; by Pulover, joedf: https://autohotkey.com/board/topic/83159-solved-removing-windows-taskbar-icons/
; How to remove (or add) the taskbar button of a window
; remove: n = 5, add: n = 6
IID_ITaskbarList := "{56FDF342-FD6D-11d0-958A-006097C9A090}"
CLSID_TaskbarList := "{56FDF344-FD6D-11d0-958A-006097C9A090}"
tbl := ComObjCreate(CLSID_TaskbarList, IID_ITaskbarList)
DllCall(NumGet(NumGet(tbl+0), 3*A_PtrSize), "ptr", tbl)
DllCall(NumGet(NumGet(tbl+0), n*A_PtrSize), "ptr", tbl, "ptr", winId)
ObjRelease(tbl)
}
Code: Select all
; The TM_WorkAround() function ensures that an AHK program without a permanent gui
; will appear correctly in TM even if the program is started from another AHK program.
#SingleInstance, Force
#Persistent
#NoTrayIcon
TM_WorkAround()
RETURN
^!+t::
If WinExist("ATempGui")
Gui ATempGui: Destroy
Else
Gui ATempGui: Show, w300 h300, ATempGui
Return
TM_WorkAround()
{
Gui TMWAGui: +HwndTMWAGuiId
Gui TMWAGui: Show, x0 y0 w0 y0
IID_ITaskbarList := "{56FDF342-FD6D-11d0-958A-006097C9A090}"
CLSID_TaskbarList := "{56FDF344-FD6D-11d0-958A-006097C9A090}"
tbl := ComObjCreate(CLSID_TaskbarList, IID_ITaskbarList)
DllCall(NumGet(NumGet(tbl+0), 3*A_PtrSize), "ptr", tbl)
DllCall(NumGet(NumGet(tbl+0), 5*A_PtrSize), "ptr", tbl, "ptr", TMWAGuiId)
ObjRelease(tbl)
}
Re: An unsatisfactory behavior of the Run command?
No, you merely fail to understand that AutoHotkey is not behaving differently to other programs in this respect. If I expand Visual Studio or Visual Studio Code, I find processes of several different executable files grouped together (hidden console windows, sandbox processes, compilers, etc.). This occurs because (or when) the child processes have no visible windows.newbieforever wrote:But I have the feeling that your answer ignores a small more fundamental aspect. If AHK behaves differently in one point on Windows than other programs, [...]
As an example of correct grouping, SciTE4AutoHotkey uses AutoHotkey to implement its toolbar. This child process is definitely part of the main program, not a separate "application"; the main process and child process cannot function correctly without each other. SciTE4AutoHotkey itself is written in C++, and uses ShellExecuteEx to launch the toolbar. This is one of the functions Run uses.
The other function Run uses is CreateProcess. SciTE4AutoHotkey uses this same function to launch scripts (when you press F5), and these are also grouped under SciTE4AutoHotkey in Task Manager. If I had ever noticed this before, I might have found it useful.
Seriously, theoretically and pragmatically, only Task Manager is responsible for the grouping of processes within Task Manager. AutoHotkey has no control over the behaviour except to provide you with the tools to work around it if you wish (at the cost of certain side-effects). Working around it by default, by using an unreliable worker process (Explorer) to launch the process, would be inappropriate. It would add overhead and change the behaviour of many scripts in possibly undesirable ways:emotionally we can pass the buck to Windows, but seriously (= pragmatically) only AHK can be held responsible.
- The child process would no longer inherit the environment variables of the parent script.
- The child process would typically not run as administrator even if the parent script was.
- If something has gone wrong with Windows Explorer, or the system has an alternative shell, it may function incorrectly or fail.
How you want the grouping to work clearly isn't the way it actually works. Consider that someone else might want the grouping the way it is.
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: An unsatisfactory behavior of the Run command?
@lexikos:
In this discussion, of course, I have to assume that I am wrong and you are right in everything. So ignore this my answer, if it's too stupid for you.
I also know that the two workarounds are not suitable as default.
But: Imagine a program that should be used like a private desktop, with links on it, with which certain applications should be launched. Some of these applications could be compiled AHK scripts without a permanent gui.
We now write this DT program in two variants, but with completely identical functionality: one in AHK, one e.g. in FreeBasic.
However, the two DT programs behave differently with respect to the TM problem described above. Can we really say stubbornly in this constellation that AHK has nothing to do with it? Especially since this constellation makes it obvious that AHK is completely illogical in this point: A program launched from a desktop has nothing to do with the DT program and should not appear as its "child".
Where does Windows find a reason to treat the two DT programs differently? Should not this reason be identified to see if a default solution would be possible?
I assume that you will also classify these points of view and arguments as wrong.
In this discussion, of course, I have to assume that I am wrong and you are right in everything. So ignore this my answer, if it's too stupid for you.
I also know that the two workarounds are not suitable as default.
But: Imagine a program that should be used like a private desktop, with links on it, with which certain applications should be launched. Some of these applications could be compiled AHK scripts without a permanent gui.
We now write this DT program in two variants, but with completely identical functionality: one in AHK, one e.g. in FreeBasic.
However, the two DT programs behave differently with respect to the TM problem described above. Can we really say stubbornly in this constellation that AHK has nothing to do with it? Especially since this constellation makes it obvious that AHK is completely illogical in this point: A program launched from a desktop has nothing to do with the DT program and should not appear as its "child".
Where does Windows find a reason to treat the two DT programs differently? Should not this reason be identified to see if a default solution would be possible?
I assume that you will also classify these points of view and arguments as wrong.
Re: An unsatisfactory behavior of the Run command?
If the "e.g. in FreeBasic" program uses either of the two standard Windows functions for launching other processes, it would not behave differently to AutoHotkey. I have already given three concrete examples of other programs which behave the same as AutoHotkey. Is your example hypothetical or real? If the latter, do you have source code?However, the two DT programs behave differently with respect to the TM problem described above.
If such a case actually happened, the two programs are doing two completely different things. For example, AutoHotkey is launching a child process, while the other program is not launching a process directly (i.e. it is routing the request through a separate process, such as with ShellRun, or Task Scheduler). The other program is the exception, not AutoHotkey.Where does Windows find a reason to treat the two DT programs differently?
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: An unsatisfactory behavior of the Run command?
I'm not a programmer, but maybe the following example has some relevance.lexikos wrote:Is your example hypothetical or real?
The executable to be launched:
AHKwithoutGUI.exe:
Code: Select all
#SingleInstance, Force
#Persistent
RETURN
^F10::
MsgBox AHKwithoutGUI.exe (an executable without a permanent gui)`r`nIS RUNNING!
Return
An AHK-written launcher:
Run_AHK.exe:
Code: Select all
#SingleInstance, Force
Run %comspec% /k "%A_ScriptDir%\AHKwithoutGUI.exe", , Hide
MsgBox, , Run_AHK.exe (AutoHotkey), AHKwithoutGUI.exe was launched by me.`r`nLeave this MsgBox open and`r`ntest the running AHKwithoutGUI.exe by Ctrl+F10.`r`nLook how AHKwithoutGUI.exe is displayed in Task Manager`r`n(with or without its MsgBox).
Run_FB.bas:
Code: Select all
#include "windows.bi" ' only for MessageBox
Shell "START AHKwithoutGUI.exe"
MessageBox(0, "AHKwithoutGUI.exe was launched by me." & chr(13, 10) & "Leave this MsgBox open and" & chr(13, 10) & "test the running AHKwithoutGUI.exe by Ctrl+F10." & chr(13, 10) & "Look how AHKwithoutGUI.exe is displayed in Task Manager" & chr(13, 10) & "(with or without its MsgBox).", "Run_FB.exe (Freebasic)", 0)
All 3 executables attached.
- Attachments
-
- Two launchers.zip
- (713.93 KiB) Downloaded 15 times
Re: An unsatisfactory behavior of the Run command?
You are not doing the same thing in both languages.
- Remove START and AHKwithoutGUI.exe will appear as a child of Run_FB.exe.
- Use Run %comspec% /c START "" "%A_ScriptDir%\AHKwithoutGUI.exe", , Hide and AHKwithoutGUI.exe will not appear as a child of Run_AHK.exe.
- If you use CreateProcess from FreeBasic, it has the same effect as from AutoHotkey: the processes are grouped.
Code: Select all
#include "windows.bi" ' only for MessageBox
Shell "AHKwithoutGUI.exe"
MessageBox(0, "AHKwithoutGUI.exe was launched by me." & chr(13, 10) & "Leave this MsgBox open and" & chr(13, 10) & "test the running AHKwithoutGUI.exe by Ctrl+F10." & chr(13, 10) & "Look how AHKwithoutGUI.exe is displayed in Task Manager" & chr(13, 10) & "(with or without its MsgBox).", "Run_FB.exe (Freebasic)", 0)
Code: Select all
#SingleInstance, Force
Run %comspec% /c START "" "%A_ScriptDir%\AHKwithoutGUI.exe", , Hide
MsgBox, , Run_AHK.exe (AutoHotkey), AHKwithoutGUI.exe was launched by me.`r`nLeave this MsgBox open and`r`ntest the running AHKwithoutGUI.exe by Ctrl+F10.`r`nLook how AHKwithoutGUI.exe is displayed in Task Manager`r`n(with or without its MsgBox).
Code: Select all
#include "windows.bi"
' From https://www.freebasic.net/forum/viewtopic.php?p=148901
Dim ExeFile As String = "AHKwithoutGUI.exe"
Dim CommandLine As String = ""
Dim As STARTUPINFO siStartInfo
Dim As PROCESS_INFORMATION piProcInfo
siStartInfo.cb = SizeOf( STARTUPINFO )
CreateProcess( _
ExeFile, _ ' exe file name
CommandLine, _ ' command line
NULL, _ ' process security attributes
NULL, _ ' primary thread security attributes
FALSE, _ ' handles are not inherited
CREATE_NEW_PROCESS_GROUP, _ ' creation flags
NULL, _ ' use parent's environment
NULL, _ ' use parent's directory
@siStartInfo, _ ' STARTUPINFO pointer
@piProcInfo _ ' receives PROCESS_INFORMATION
)
MessageBox(0, "AHKwithoutGUI.exe was launched by me." & chr(13, 10) & "Leave this MsgBox open and" & chr(13, 10) & "test the running AHKwithoutGUI.exe by Ctrl+F10." & chr(13, 10) & "Look how AHKwithoutGUI.exe is displayed in Task Manager" & chr(13, 10) & "(with or without its MsgBox).", "Run_FB.exe (Freebasic)", 0)
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: An unsatisfactory behavior of the Run command?
@lexikos:
Ok I understand.
But then we have here ("surprisingly") another workaround for the TM problem, right?
Maybe the most suitable.
Would not such a Run() function be a generally viable alternative to the Run command?
Run_AHK.ahk
I did not succeed in incorporating the OutputVarPID option into the function to achieve the functionality of the Run command.
In my project the function works perfectly. But you will surely find again that such a function is not generally usable as a run method of choice in AHK (undesirable side-effects).
Ok I understand.
But then we have here ("surprisingly") another workaround for the TM problem, right?
Maybe the most suitable.
Would not such a Run() function be a generally viable alternative to the Run command?
Run_AHK.ahk
Code: Select all
#SingleInstance, Force
Target = AHKwithoutGUI.exe
Parameters = "One č" "Two š" "Three ž"
WorkingDir = %A_ScriptDir%
Run(Target, Parameters, WorkingDir)
MsgBox, , Run_AHK.exe (AutoHotkey), AHKwithoutGUI.exe was launched by me.`r`nLeave this MsgBox open and`r`ntest the running AHKwithoutGUI.exe by Ctrl+F10.`r`nLook how AHKwithoutGUI.exe is displayed in Task Manager`r`n(with or without its MsgBox).
RETURN
Run(Target, Parameters, WorkingDir) {
Run %comspec% /c START "" %Target% %Parameters%, %WorkingDir%, Hide
}
In my project the function works perfectly. But you will surely find again that such a function is not generally usable as a run method of choice in AHK (undesirable side-effects).
Re: An unsatisfactory behavior of the Run command?
You've already found one limitation that makes it unsuitable as a replacement for the Run command. Here are a few more:
- It cannot elevate processes (*RunAs).
- It cannot execute other verbs, such as print or edit.
- It changes the interpretation of some special symbols (such as > and | for redirection/piping, & for executing multiple commands, etc.).
Who is online
Users browsing this forum: Google [Bot], LeafyWater and 167 guests