I am making a windows-form which contains a console. now when the console is openend and i later close either the console or the form( automaticly closes console too ) The proces of the console stays online when i look inside the taskmanager.
How is this possible? and why is this happening?
And, when i call the console it somehow doesn't get updated. this means
when i make any changes in the console inside visual studio, than save, start the program. It still uses the version BEFORE the save.
How is this possible, and why is this happening?
thank you
EDIT:
I have a seperate project in my solution called "parts' this is the console. I start i using
Console = Process.Start(#"C:\Users\Krijn\Desktop\CarWorks\Parts\bin\Debug\Parts");
As aleady mentioned you start a new process. The new process is independent from the one starting it. You need to terminate the started process yourself, I would suggest something like this:
Process consoleProcess = Process.Start(#"C:\Users\Krijn\Desktop\CarWorks\Parts\bin\Debug\Parts");
// Do some stuff here...
if (!consoleProcess.HasExited)
{
// Terminate the process
consoleProcess.Kill();
}
// Wait until the process is really terminated.
consoleProcess.WaitForExit();
Related
It just came to attention that every time we run the c# console application, at the end it shows text stating "Press any key to continue... ".
And the moment you hit any key, it terminates the console/program.
In actual program there is no mentioning about such text printing on standard output console, then from where and why it comes out on screen?
Can someone explain the logic behind?
Code:
static void Main(string[] args)
{
Console.WriteLine("Test Application");
}
Output:
Test Application
Press any key to continue . . .
It has nothing to do with your application itself. When you double-click on the output EXE file you'll not see it. It is only when we run the app from within Visual Studio without the debugger attached when this behavior is seen.
When you press Ctrl+F5, Visual Studio is running your app in a way that causes the console window to remain open.
I think it comes from cmd parameters that are used. Something like :
%COMSPEC% /k "C:\VS\MyApplication.exe"
Do you use CodeBlocks ?
If yes, it is a Feature of CodeBlocks. That you can read the Output without to write something like getChar() at the end that the console stay open. Otherwise it would close instantly and you can't read the output.
In normal application the console will close when done and that is the expected behaviour. This prompt simply helps you to check the results of your code when you are writing your application and you do not have to put (and remember about later removal) of the:
Console.ReadLine();
in your application just to test it and see what the output is.
I am hoping to check at the beginning of an automated test if an application is open. I can check if the process is running by doing the following
foreach (Process proc in Process.GetProcesses())
{
if (proc.ProcessName.Contains(name))
{
return true;
}
}
However, the process I want to find starts up about a minute before the application actually opens and is ready to be used by the test methods (its a very slow starting application). The above code sample looks at all windows processes running, but I am wondering, is there a way to do a similar method but to look at windows applications running?
There is a method already in class Process that you can use to check if an app with a UI has fully started:
Process.WaitForInputIdle(int milliseconds)
This will wait up to milliseconds ms for the message loop to become idle (and returns a bool to indicate success status). Depending on the application you're waiting for, you might want to allow 30 seconds or longer.
This might work for you, but be aware that in my experience for some applications it is not totally reliable!
The Windows API documentation has more details about the Windows API function that WaitForInputIdle() calls behind the scenes.
When a process is started, you can say application has started.
What you want is to wait until application startup progress has completed or not.
This means, when process is started, application startup begins. When application startup is completed, is becomes ready for user input. So I think you should have a look at following question and its answers.
Programmatically, how does this application detect that a program is ready for input
Apllication is proces.
If you can modify app, at app start you can create file and at end delete it. So you can chceck file existance. If file exist app starting/started.
If you need info when main form is created use:
WINFORMS
Form.Shown event.
WPF Loaded Event
uITestControl.Exists did the trick for me.
This method will return a boolean value corresponding to the existence of the application window being open. This allows an if statement to be created that can open the application if not already open, or do nothing if its already open.
I am writing a simple C# console application in VS 2013 but the problem is that output screen flashes for a moment and disappears suddenly . I use the alternate way and write Console.Readline() method in the end and problem is fixed .So but i personally think that this is just a trick to stop the screen and not the proper way.So can anyone explain me the proper way of doing this ??
The program immediately closes because there's nothing stopping it from closing. Insert a breakpoint at return 0; or add Console.Read(); before return 0; to prevent the program from closing.
After you are done with your program, press Ctrl+F5 ( Run without
debugging). This will prompt before closing the window and this is
what you want.
Or use this line at the end
Console.ReadKey();
No, this is the correct way of doing it. Console.ReadLine() and Console.ReadKey() are a blocking statement: they halt the thread to wait for input before continueing. If you wouldn't do this the program would reach its end and thus exit the console.
In a larger console program you might have a while(running) loop instead and a GUI won't have this problem until its GUI thread is explicitly stopped (closing the window), but for a simple console app you can just use this 'trick'.
Yes, as long as you don't stop the application it keeps running and ends when done processing.
That's why you need the Console.ReadLine(), it stops processing and waits until you tell it to continue.
when you run the program in Debug mode if you do'nt have any BreakPoints or if .NET engine does not need to Read IO from user then it just finishes the excution without waiting anymore.
if you want to stop the execution at the end want to see the console screen you can either use any IO Read Statements as below:
Console.ReadLine();
Console.Read();
Console.ReadKey();
OR
You can run your program in without Debugging mode by simply pressing Ctrl+F5
I have c# application that I am running, and then in some point application throws an error which is then catched, then app should end. And it ends, but console windows stays open...
I even checked in windows task manager, under applications tab, there is listed my console, but when I click go to process, there is no process of that application.
Thats weird... Application ended, process ended, but console stays on? How can I kill that console?
Edit: my code:
static class Program
{
static void Main()
{
try
{
//bunch of static methods from other static classes are being invoked
Setup.Driver.Close();//another static method
}
catch (Exception)
{
Setup.Driver.Close();
}
}
}
Second edit: Note: Process.Getprocess().Kill(), Application.Exit(), Environment.Exit() are not working for me, in windows task manager, there is no process left to kill, only console stays open!
Environment.Exit(0);
or
this.Close();
If you have threads running, you can try this brute force method before you call Exit:
using System.Diagnostics;
ProcessThreadCollection currentThreads = Process.GetCurrentProcess().Threads;
foreach (var thread in currentThreads)
{
thread.Interupt(); // If thread is waiting, stop waiting
// or
thread.Abort(); // Terminate thread immediately
// or
thread.IsBackGround = true;
}
Environment.Exit and Application.Exit
Environment.Exit() is cleaner.
http://geekswithblogs.net/mtreadwell/archive/2004/06/06/6123.aspx
Good morning,
is the console app not closing when you start it from Visual Studio with the debugger attached or is it also not closed when you launch it from the file system / without attached debugger?
When the debugger is attached, you will always see an 'Press ENTER to exit ...' (or similar message).
When talking about the task manager - do you see the *.vshost process in there?
If yes, this is 'required' by Visual Studio and is not your 'real' console application; you will always see a *.vshost process when launching executables from within Visual Studio.
Hope this helps
Your program is most likely linked to another process which keeps it open.
In my case, the process was chromedriver.
Check your processes and your code to see what you opened and what's still running in the background.
I was stuck with this issue too. Once I was done with the browser, I just used Driver.Close(); However, doing this still kept chromedriver running in the background. So instead I used Driver.Quit(); . Then I made sure to return; from the Main method.
Hope this helps!
Environment.Exit();
will this work?
I have a winforms application that sometimes used from the command line.
Here is the code (simplified of course):
[STAThread]
static void Main()
{
AttachConsole(ATTACH_PARENT_PROCESS);
Console.WriteLine("Hello");
/*Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());*/
}
If that was a console application the output could be:
C:\ConsoleApplication\ConsoleApplication.exe
Hello
C:\ConsoleApplication\_
In case of windows application its actually:
C:\WindowsApplication\WindowsApplication.exe
C:\WindowsApplication\Hello
_
Can anyone tell me why do we have such difference and is it possible to make my windows application to behave like console when running from cmd?
edit:
I want my windows application to behave like console when running from cmd:
C:\WindowsApplication\WindowsApplication.exe
Hello
C:\WindowsApplication\_
solution:
As a result I'm running my application as
C:\WindowsApplication\start /wait WindowsApplication.exe
Yes. The difference is that cmd.exe is aware of the kind of executable. It knows to wait for the process to terminate when it is a console mode app. It does not wait when it is a regular Windows gui app. Trusting that it will create its own window. So it displays the command prompt again, your output gets appended to that. You'll also have trouble using Console.ReadLine() btw.
You'd have to start your program with start /wait yourapp.exe to force cmd.exe to wait. Calling AllocConsole() instead is the only universal fix. Also takes care of creating the console when your app gets started from a shortcut.
AllocConsole() is fairly disorienting. Consider writing a tiny console mode app that does nothing but Process.Start + WaitForExit to start your main program. Perhaps also munging the command line arguments. Now you get the blocking behavior back. If you rename the executable to mainapp.com (to start mainapp.exe) then the difference is hidden quite well, a trick that VS uses as well (devenv.exe vs devenv.com).
There is a flag in the exe, telling if this is a console app or gui (winform in your case) app. When you start an app, Windows will detach the console from the program if it is a console app. You can use the following approach to achieve what you want:
Compile you application as gui, name it mytool.exe
Create a doskey alias mytool=start /wait c:\path\mytool.exe $*
In this way, when you start mytool.exe in explorer or shortcut, you start a normal windows application; when you type in mytool in console, you actually start it by "start /wait", which will not detach the console regard less of the flag. (However, you do need to attach to parent console in your app if you want to output/input something from the console.
You want the Windows App to block the Console thread as long as it's running, if I understand you correctly. I have no idea why you would do that, but I can give a shot at how it might work:
Change the WinForms application to a console application, that opens a form. This way it would block the console thread while displaying a window.