RunAutomationStep won't show a full-console application to user but keep it in background
Ace-Radom opened this issue · comments
Rules
- I made myself familiar with the README.
- I checked closed issues for similar ones and did not find a similar problem mentioned before.
- I understand that, if insufficient information was provided, my issue will be closed without an answer.
Version
2.20.2
OS
Windows 11 23H2
Device
Legion R9000p 2021H
BIOS version
GKCN53WW
What's wrong?
Inspired by #1214.
I just tried to run a full-console application (with absolute no GUI, it's a shell-like software) with RunAutomationStep
and figured out that the executable is started successfully, but it is not shown on the screen. It is started and ran as a sub-process of LLT.
![image](https://private-user-images.githubusercontent.com/104905842/311018099-49cd6f72-278e-45c3-a051-6329e8e35535.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTg4ODA0NzQsIm5iZiI6MTcxODg4MDE3NCwicGF0aCI6Ii8xMDQ5MDU4NDIvMzExMDE4MDk5LTQ5Y2Q2ZjcyLTI3OGUtNDVjMy1hMDUxLTYzMjllOGUzNTUzNS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNjIwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDYyMFQxMDQyNTRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03ZTY2ZGM0NjQ2ZGVlNWRiZjdiODJiOWEwYTM0ZjQwZGZlNjc2MWRjNTgwYWNmYTA4ZWFlNjExMzdiYTIxNDhjJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.O_sM5MbwnhvTxsf_whbxaztT2w0J7eVszpM-5dG7XNk)
You can also take a look at the taskbar: neither Windows-Terminal nor CMD was opened. I checked the return of CMD.RunAsync
function called by RunAutomationStep.Async
, no error was found.
I personally think that it is caused by the following settings:
LenovoLegionToolkit/LenovoLegionToolkit.Lib/System/CMD.cs
Lines 15 to 22 in f22d96e
Here Process.StartInfo.CreateNoWindow
is set force to true
. According to what I know with the original WINAPI CreateProcess
function, it is expected that no window is shown when a full-console executable being launched and dwCreationFlags
setting to CREATE_NO_WINDOW
. Although I'm not familiar with the C# Process class, but I think it is the same.
And it leads to the problem: these codes work fine when user trying to open an application with GUI, but if not, it sucks. If the user only wants to run a python script, for example, he cannot get any output from the script because the window is hidden.
How to reproduce the bug?
- Go to
Actions
and add a new trigger - Add a
Run
step to the action - Set a full-console application in
Executable Path
- Click
Run now
, the application is running but hidden
What is the behavior that you expected?
Users should have the ability to select if their application (or sth weird) should be launched with a no-window-argument or not. Adding a combobox would fix this problem I think.
I tried to do it on my own but I was confused by the listeners and other stuffs. It's out of my league.
Logs
The problem was reproduced, no console was shown.
Additional information
No response
Yes, that's by design, but I am
Not against a checkbox to show Window.
Yes, that's by design, but I am
Not against a checkbox to show Window.
I see...should I continue working on this or you'll do it in your free time.
If you have time, by all means go for it. Add a checkbox, add optional parameter to the method you linked and that's pretty much it. You can draft a PR and we will take it from there.
One more thing: recently the behavior had to be changed a bit. But, AutomationProcessor will be blocked until the process finishes. Which means that if you start something like figlet above, next step in the action won't run until figlet finishes executing. So we can extend this feature by adding one more checkbox "Wait for exit" that could override this behavior.
I imagine we could call these boxes: "Run silently" for the no window flag (default true") and "Wait until finished" (default true) for the 'waitForExit' flag.
But, AutomationProcessor will be blocked until the process finishes. Which means that if you start something like figlet above, next step in the action won't run until figlet finishes executing. So we can extend this feature by adding one more checkbox "Wait for exit" that could override this behavior.
I didn't test such a step-by-step chain by I'll take a look.
I imagine we could call these boxes: "Run silently" for the no window flag (default true") and "Wait until finished" (default true) for the 'waitForExit' flag.
That's a good idea, will add them to resource.