I have a C# VS2017 Console App. I'd like the CMD prompt to return immediately after executing while the App runs in the background (it's a long running process).
Currently I'm starting the App as a Process from another executable just to do this by setting Process.StartInfo properties.
Is there an opposite to Process.WaitForExit() that can be set at the start of a program?
I read somewhere using a WinForms App without the form might work, yet I tried to delete the form and sleep for 10 seconds, showing a MessageBox after (in Main). The program returned and showed the box immediately without sleeping.
I have an application that launches a process using Process.Start. The process will either show up the actual window after a few seconds (depending on how much time it took to load), or will show a MessageBox with an error message.
After I'm using Process.Start, I want my application to wait until either the window showed up or the MessageBox showed up. I tried using WaitForInputIdle and checking if Handle is 0, but they both don't work.
How can I wait until the process emits an actual window?
I think you should just catch window openings with Automation as recommended here:
Most Efficient Way for getting notified on window open
The question here is if anyone has an idea how to both get StandardOutput data to print in Windows form application and keep the output in the console itself. The WinForms part I have completed already, it works great with process events and invoking form elements. At this point I am pretty sure that after re-directing output, Console.Writeline() doesn't print anything on the console window anymore. Any ideas besides running another dummy process that simply displays anything whats on InputStream?
Also
While I'm at this. Is there any way to access process that is on another thread? Since whenever I try to access it it shows that its out of scope.
I am trying to writing a console application. It has its original console, let's name it console A. And I want this application to do the following things via C#:
Open another console B in another thread, then get input from A and output it to B;
type a command in A, such as dir, and show the output in B;
while doing the above things (still not done yet. X_X ), I find myself lack a through understanding of what a console window is, and how it is assigned to a console application, especially the very first console when my console application starts to run. Could some one shed some light on me?
Is console window physically a memory area in the video memory? Or something else?
Could different threads within the same process have different console of its own for its own I/O?
Many thanks.
Now I am using one console application to start another console application in a new process. Thus I can have 2 consoles output at the same time.
My understanding now is that, for Windows OS, a console is a special window, and it's a system resource that OS assigned to the application without-a-UI as a necessary user interface. Windows OS handles the wiring between the system-prepared console window with our UI-less application.
In Windows terms, a Console is a textual GUI window that you see when you run "cmd.exe". It allows you to write text to, and read text from, a window without the window having any other UI chrome such as toolbars, menus, tabs, etc,..
To get started you'll want to load Visual Studio, create a new project and choose "Console Application". Change the boilerplate code that Visual Studio produces to:
using System;
using System.Text;
namespace MyConsoleApp
{
class Program
{
static void Main(string[] args)
{
Console.Write("Hello, world!");
Console.ReadKey();
}
}
}
When you run your application, a console window will open with the text "Hello, world!" and it'll stay open until you press a key. That is a console application.
Is console window physically a memory area in the video memory? Or something else?
It's not physically a memory area in video memory, it's "something else". The Wikipedia Win32 console page gives a fairly robust descrption of the ins and outs.
A console application has only one window. It does not have window management functions in order to spawn child "consoles".
You can start additional console applications, but these are separate entities.
No. It's a windows GUI subsystem. In WinAPI there are functions to work with console: http://msdn.microsoft.com/en-us/library/ms682073%28VS.85%29.aspx
A (OS) console is a process (containg one or more threads of executions, all of them sharing the same memory space), and this process has:
standard input (a stream of input bytes), what you key in
standard output (a stream of output bytes), what the program prints
standard error (a stream of output bytes), what the program prints when it's complaining about something
So if you want to create another console (from .Net) and link the input/outputs I understand you have to create a process (executing "cmd.exe" by example).
I don't know the API of .Net for process manipulation but if it's like Java you can hook up stdin, out and err so you can play with your created process from the original one.
A windows application can have one console, or no console, it can't have more than one. See the documentation for AllocConsole.
The console is basically an emulation of the 'pre-Windows' days when there would literally be a 'control console' i.e. a keyboard and screen attached to a mainframe computer.
To do what you want you could spawn another process with its own console and communicate between the two, or make a GUI application which looks like a console window.
I have a graphical control that is multithreaded.
Until now it worked fine, but I just noticed that whenever I'm on my application showing this control the following happens: if I lock and unlock my workstation, it freezes, like if it were in some kind of infinite loop.
Even stranger, this bug occurs only when I'm not launching the app from Visual Studio, and not attached to it.
Does anyone have a clue on what's happening?
For instance, if I attach Visual Studio to the already freezed app, can I see which lines of code my threads are executing?
Any help will be appreciated!
We recently had (for about a year and a half ;) this same problem. It also triggers sometimes when IE flushes caches, when you change colors of you theme. etc.
The problem was that we had a splash screen that had its window created on one thread and then it was shown (ShowDialog()) within other thread. Once we moved the window creation to the same thread that actually shows it, it resumed. There was also some changes with .Dispose():ng the splash window, and they could also have had an effect.
Microsoft has an article about this and they basically suggest to run their Spy++ program and look at your program when it's hung. There is a "Windows" -window, search for your application and look for any windows that should not be there. They possibly have a windows message pump active/attached but it is not pumping. The "change" message does not get handled and all .NET windows stall -> hang.
just attach VS to the frozen app and hit Pause button, VS will show executing code.