I've been thinking of giving the in Windows implemented cmd a fresh look and make a WinForm out of it(C# .net4.0 or later or latest mono# distribution).
Now, what I plan on doing is:
only showing the form, no console visible(even in the task bar)
telling the cmd what to do by virtually typing into it
catching the consoles output and using the form to make the user interact
I thought of some kind of "return" thing, like a dll would do, but I have not used consoles and forms together in a single project, so there's my question:
How do I not show a console window but write commands into it's line and receive the output with a WinForms application?
Thanks in advance.
--EDIT
I should maybe add that my main problem is typing catching the consoles output and also typing into it while it's not visible and thus not focusable.
You may well run into difficulties other than simply suppressing the appearance of a console window. But as far as that particular requirement goes, it's not hard.
You'll use the System.Diagnostics.Process class to start the process. Before starting the process, you'll need to see ProcessStartInfo.CreateNoWindow property to true. Note that you also need to set ProcessStartInfo.UseShellExecute to false, otherwise the CreateNoWindow property is ignored.
As for the broader problem: it seems likely that you'll need to start the console process using "cmd.exe /k" to instantiate a new command-line interpreter process without it exiting before you're done with it. Then you'll also need to use the redirection features in the Process class to read from stdout and stderr, and to write to stdin.
Related
I want to make a GUI Windows application that can run console applications. When this happens, the console window should not be shown. Instead its content should be shown in a visual component (memo/richedit). This component should show exactly the same content which would appear in the console window, even the color of the text and its background should be displayed. So this visual component should work exactly as a console window. I know that the standard output can be captured but many console applications do not use it. Is it possible to capture the output of a console application this way? Are there Windows API calls that can handle this?
I use Delphi XE2 but C# code would also be helpful.
You have to run the console mode program with stdout redirection to a pipe that your Delphi program will create. Your Delphi program can read the pipe to get the console mode program output and do whatever it needs to. By the way, this works not only with Delphi but also with any language able to create pipe and run program with I/O redirection.
If you need Delphi code to do that, have a look at this reference.
There is a ready-to-run component on GitHub: DosCommand
The Demo shows two ways how to do what you describe.
I am not sure if it works for older versions like XE2, but at least you can give it a try.
Traditionally you would call CreateProcess with stdin/stdout set to pipes you created. This should work for most programs but not for anything that uses a ncurses style "GUI" and you also lose the color information. An example can be found on MSDN.
Windows 10 (1809?) added support for pseudoconsoles. This is used by the new Terminal application and is your best bet for full console compatibility.
The last alternative is to inject into the child process and hook WriteFile, ReadFile and all the console functions but this is ugly and error-prone.
Here's the situation: Our C# WPF application needs to parse the output that a 3rd-party console application writes to a file. Starting the process and parsing the file after WaitForExit() would be easy enough, but unfortunately the app was written such that after 20 lines of output, it stops output and waits for the user to hit return. Yes, even though it writes its output to a file, it will still pause and wait for the user to hit return before writing the next 20 lines. The 3rd-party app is completely closed source and there's no hope of recompiling it to disable this behavior. It's quirky in another respect, too: Despite being a console app, it must be run within it's own directory. Given that it's a win32 port of an old DOS app, I guess I shouldn't be surprised.
I'm aware of the usual solutions like WaitForInputIdle() or hacky win32 stuff, but I can't really find anything that suits my situation. Anything that involves finding an open window and sending input via win32 isn't an option for us since the console app can't be run in a window.
So what do you think? Have I not found the right win32 hack yet? Maybe I should wrap the console app in a winform and then I can use WaitForInputIdle()?
If it's a normal console app, simply set UseShellExecute to false and RedirectStandardInput to true, then use the StandardInput property to write a newline when needed.
Using files is an extremely outdated approach, at least 20 years past. Whenever you find yourself using them, you should consider modern standard input/output piping.
I am trying to use AppWinStyle with Process.start but it does not work as i expected.
The below code will open file 1.txt and it will be minimized with no focus to it.
Shell("notepad D:\1.txt", AppWinStyle.MinimizedNoFocus)
But below code will open 1.txt with focus on it.It will not be minimized.
Process.Start("D:\1.txt", AppWinStyle.MinimizedNoFocus)
Why does it happen? Please help me to solve this
A boilerplate example:
using System;
using System.Diagnostics;
class Program {
static void Main(string[] args) {
var psi = new ProcessStartInfo("notepad.exe");
//psi.WindowStyle = ProcessWindowStyle.Hidden;
Process.Start(psi);
}
}
Run it once to make sure it works, then remove the comment and observe the outcome. You'll briefly see the Notepad window flash but it immediately terminates again. Might depend on the Windows version, I described what happened for Windows 8.1
A GUI app gets the ProcessWindowStyle you specify through its WinMain() entry point, the nCmdShow argument passes the value you specified. What the app actually does with that value is entirely up to the app. Boilerplate implementation is to pass it to the ShowWindow() call, the one that makes its main window visible.
Using ProcessWindowStyle.Hidden is in general very problematic and a properly written GUI app will ignore it, like Notepad did. Because what you asked it to do is to start the program but not display any window, not even a taskbar button. In other words, you asked it to turn into a zombie, a process that runs without any way for the user to get to it. The only possible thing the user could do is run Task Manager and kill the process.
So sure, definitely expect this to not work. It shouldn't.
No such overload with Process.Start:
Process.Start("D:\1.txt", AppWinStyle.MinimizedNoFocus)
See all overloads here: Process.Start Method
In order to achieve it using the Process.Start, use the ProcessStartInfo.WindowStyle, setting it to ProcessWindowStyle.Minimized.
By the way, the AppWinStyle enumerator is specific for the Shell function:
Indicates the window style to use for the invoked program when calling
the Shell function.
I've got a console application and I want to run it from another application. But when I invoke it from code--to call program I use ActiveXObject--it shows the console. How do I get it to not show the console? I mean, the program works but console is shown.
If you make the application a Windows Application instead of a Console Application it will not show or open (or use) a Console. Your code can stay the same - and the application will still function (without ever creating a Form or Window).
That being said, if you control the "other" application, you may want to consider making a class library instead of a separate Application. This would allow you to just include and run code within the library without starting a separate process.
You can create it as a Windows Forms application with a hidden window. That's just one possibility like Reed Copsey pointed out, i used it once because i needed to process some specific Window Messages.
I have a C# Console app than runs a pre-build step (to get NuGet Packages).
When I am debugging this, I want to pass in a parameter and show the console. When I am not debugging it I don't want to see it. I don't even want it to flash up there for a second.
I have found ways to hide it, after it has shown. But I can't find a way to never make it show unless I am willing to change it from a console app to a Windows app. (Which I would do if I could then find a way to show the Console when needed.)
Build as a Windows application and show the console when you need it. To show the console when needed use P/Invoke to call AllocConsole (pinvoke.net has the declaration you need).
(Console sub-system processes always get a console, their parent process's if there was one, otherwise a new one. This is the way Windows works at a deep level.)
Use FreeConsole WINAPI function:
http://pinvoke.net/default.aspx/kernel32/FreeConsole.html
Another solution is to simply switch to a WinForms application as project type. No console will be allocated then (and you do not need to show a form).