Well, best practice is never to do anything long inside an event handler (I'm assuming from context that this code is likely inside something like a button's click method, right?)
The reason is, WaitForExit() will stall the thread that calls it, and in this case it's the main GUI thread for your winform. That means, among other things, it won't even redraw your winform while the GUI's message pump is blocked. Really, you should handle this in one of two ways:
1. Move the process creation and waiting into another thread. This is how you normally need to handle time-consuming operations (and this is an excellent post on this board about how to do that, otherwise if you need more than BackgroundWorker can do, you can roll your own with Thread & BeginInvoke/Invoke), but in this case there's a better answer because all you're doing is waiting for a process to end:
2. Rather than use WaitForExit(), handle the process's exit event. Your code would then look like this (writing from memory so may not be 100% accurate but should be close):
Code:
// Inside the form class:
private System.Diagnostics.Process proc;
private void myProcess_Exited(object sender, System.EventArgs e)
{
button3.BackColor=Color.LightGreen; //success indicator
}
Code:
// In whatever method was spawning the process:
System.Diagnostics.ProcessStartInfo p = new System.Diagnostics.ProcessStartInfo(@"C:\OtherProgram.exe") ;
p.Arguments="-RunForever";
proc = new System.Diagnostics.Process();
proc.StartInfo = p;
proc.EnableRaisingEvents = true;
proc.Exited += new EventHandler(myProcess_Exited);
proc.Start();
This way, your GUI thread never stalls at all -- it simply continues its message pump until it receives a message that the other thread ended. Previously, the entire message pump would grind to a halt until the other process exited.
You may find that you now need to disable certain UI elements (buttons, menus, etc.) while the other process runs (previously, none of them would work because the wait was blocking new input from being processed at all).
Personally, my rules-of-thumb on any event handler are:
* Prefer events to waits whenever possible. The message pump does a great job at waiting until something happened and then dealing with it. Use it, don't duplicate it and certainly don't break it.
* Anything (including a wait, when necessary) which takes longer than a few seconds should be moved into its own thread (preferably also giving the user regular status updates on its progress).
The first is just better practice in general; the second is simply a promise I make to the users of my app: any application I make should never stall for more than a few seconds while processing your last request.