We Keep Coding

Possible to get output of a process

I have a third party DOS process which writes data about its progress to the command line.
I want to react on the progress. Normally I would use a Process with RedirectStandardOutput = true and RedirectStandardError = true and then
.OutputDataReceived +=xyzOutputDataReceived;
.ErrorDataReceived += xyzErrorDataReceived;
.Start();
.BeginOutputReadLine();
.BeginErrorReadLine();
Normally this works. and I got what i need as DataReceivedEventArg.
In this case the process seems to update the same line it has written (how is that possible?), so it writes 15 %, 15% changes to 18% and so on. Only at the end of execution it seems that the data is flushed to StandardOutput.
Also if i just try to pipe data to a text file (eg odb.exe >> output.txt) it shows nothing.
Is there any way to get the temporary data?
The question is not about getting the Standard Output, this works fine (synchronously and asynchronously). It is about how to get output from a process which I cannot change, and which does not seem to flush it's output to the standard stream.

Like juharr says, you need to use Win32 to screen scrape the console.
Fortunately you don't need to write that code yourself. You can use the buffer-reader from this post: https://stackoverflow.com/a/12366307/5581231
The BufferReader reads from standardout. I suppose you are writing a wpf or winforms application so we'll also have to get a reference to the console window of the DOS application. For this, we will use the Win32 API call AttachConsole.
[System.Runtime.InteropServices.DllImport("kernel32.dll")]
private static extern bool AttachConsole(int pid);
I wrote a small example program that demonstrates the usage. It starts the exe and attaches to its console. It then scrapes the entire window once a second, and dumps the output to the debugger output window. You should be able to modify this to search the console content for any keywords etc. that you can use to track the progress of the program. Or you could dump it to a textfield or something in your UI, possibly after comparing it for changes?
var process = Process.Start(#"..path to your exe....");
//Wait for the DOS exe to start, and create its console window
while (process.MainWindowHandle == IntPtr.Zero)
{
Thread.Sleep(500);
}
//Attach to the console of our DOS exe
if (!AttachConsole(process.Id))
throw new Exception("Couldn't attach to console");
while (true)
{
var strings = ConsoleReader.ReadFromBuffer(0, 0,
(short)Console.BufferWidth,
short)Console.BufferHeight);
foreach (var str in strings.
Select(s => s?.Trim()).
Where(s => !String.IsNullOrEmpty(s)))
{
Debug.WriteLine(str);
}
Thread.Sleep(1000);
}
Good Luck!

How to stop a process after you run it?

This is the code I used to run the following exe program. How can I end this 3 process after I had run it?
Process.Start(#"C:\Bot-shortcut\DIE1.exe");
Process.Start(#"C:\Bot-shortcut\DIE2.exe");
Process.Start(#"C:\Bot-shortcut\DIE3.exe");

First, store the process object returned when you start the process.
If you want it to close normally, as though someone had clicked the close icon, then use CloseMainWindow. This simulates clicking the close icon so that the process can shut down normally. This is always preferable to killing the process, which can corrupt data.
If you want it to die instantly then use Kill. Note that this can corrupt data; the process might have been writing to a file when you killed it.

You have to get the process by Name and then stop it.
Here is the code snippet from MSDN:
Process[] myProcesses;
// Returns array containing all instances of Notepad.
myProcesses = Process.GetProcessesByName("Notepad");
foreach (Process myProcess in myProcesses)
{
myProcess.CloseMainWindow();
}
The Process.kill() will also stop the process but without any prompt.
Find the details in This article.

You can end your process using Kill
Process myProcess = new Process(#"C:\Bot-shortcut\DIE1.exe");
myProcess.Start();
//After Some Codes
myProcess.Kill();

Process.Start returns the process instance which you have started.
Store that in variable and use Process.Kill method to kill that process once you are done with it.
Process process = Process.Start(#"C:\Bot-shortcut\DIE1.exe");
process.Kill();

Store the process objects as variables:
var proc1 =Process.Start(#"C:\Bot-shortcut\DIE1.exe");
var proc2 = Process.Start(#"C:\Bot-shortcut\DIE2.exe");
var proc3 = Process.Start(#"C:\Bot-shortcut\DIE3.exe");
And wait for them to exit:
proc1.WaitForExit();
proc2.WaitForExit();
proc3.WaitForExit();
Or kill them:
proc1.Kill();
proc2.Kill();
proc3.Kill();

Why does closing a console that was started with AllocConsole cause my whole application to exit? Can I change this behavior?

What I want to have happen is that the console window just goes away, or better yet that it is hidden, but I want my application to keep running. Is that possible? I want to be able to use Console.WriteLine and have the console serve as an output window. I want to be able to hide and show it, and I don't want the whole app to die just because the console was closed.
EDIT
Code:
internal class SomeClass {
[DllImport("kernel32")]
private static extern bool AllocConsole();
private static void Main() {
AllocConsole();
while(true) continue;
}
}
EDIT 2
I tried the accepted solution here [ Capture console exit C# ], per the suggestion in the comments on this question. The example code is bugged in that the DLLImport needs to be "kernel32.dll" or "kernel32", not "Kernel32". After making that change, I'm getting a message to my handler for CTRL_CLOSE_EVENT when I click the X on the console window. However, calling FreeConsole and/or returning true doesn't prevent the application from terminating.

Ah, yes, this is one of the caveats of using the Windows console subsystem. When the user closes the console window (regardless of how the console was allocated), all of the processes that are attached to the console are terminated. That behavior makes obvious sense for console applications (i.e., those that specifically target the console subsystem, as opposed to standard Windows applications), but it can be a major pain in cases like yours.
The only workaround that I know of is to use the SetConsoleCtrlHandler function, which allows you to register a handler function for Ctrl+C and Ctrl+Break signals, as well as system events like the user closing the console window, the user logging off, or the system shutting down. The documentation says that if you're only interested in ignoring these events, you can pass null for the first argument. For example:
[DllImport("kernel32")]
static extern bool SetConsoleCtrlHandler(HandlerRoutine HandlerRoutine, bool Add);
delegate bool HandlerRoutine(uint dwControlType);
static void Main()
{
AllocConsole();
SetConsoleCtrlHandler(null, true);
while (true) continue;
}
That works perfectly for Ctrl+C and Ctrl+Break signals (which would have otherwise caused your application to terminate as well), but it doesn't work for the one you're asking about, which is the CTRL_CLOSE_EVENT, generated by the system when the user closes the console window.
Honestly, I don't know how to prevent that. Even the sample in the SDK doesn't actually allow you to ignore the CTRL_CLOSE_EVENT. I tried it in a little test app, and it beeps when you close the window and prints the message, but the process still gets terminated.
Perhaps more worryingly, the documentation makes me think it is not possible to prevent this:
The system generates CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT signals when the user closes the console, logs off, or shuts down the system so that the process has an opportunity to clean up before termination. Console functions, or any C run-time functions that call console functions, may not work reliably during processing of any of the three signals mentioned previously. The reason is that some or all of the internal console cleanup routines may have been called before executing the process signal handler.
It's that last sentence that catches my eye. If the console subsystem starts cleaning up after itself immediately in response to the user attempting to close the window, it may not be possible to halt it after the fact.
(At least now you understand the problem. Maybe someone else can come along with a solution!)

Unfortunately there's nothing you can do to really alter this behaviour.
Console windows are "special" in that they're hosted by another process and do not allow sub-classing. This limits your ability to modify their behaviour.
From what I know, your two options are:
1. Disable the close button altogether. You can do this with the following code fragment:
HWND hwnd = ::GetConsoleWindow();
if (hwnd != NULL)
{
HMENU hMenu = ::GetSystemMenu(hwnd, FALSE);
if (hMenu != NULL) DeleteMenu(hMenu, SC_CLOSE, MF_BYCOMMAND);
}
2. Stop using consoles altogether, and implement your own text output solution.
Option #2 is the more complicated option but would provide you the greatest control. I found an article on CodeProject that implements a console-like application using a rich edit control to display the text (rich edit controls have the ability to stream text like the console, so they are well suited to this sort of application).

On closing the console window obtained using AllocConsole or AttachConsole, the associated process will exit. There is no escape from that.
Prior to Windows Vista, closing the console window would present a confirmation dialogue to the user asking him whether the process should be terminated or not but Windows Vista and later do not provide any such dialogue and the process gets terminated.
One possible solution to work around this is avoiding AttachConsole altogether and achieving the desired functionality through other means.
For instance in the case described by OP, console window was needed to output some text on Console using Console static class.
This can be achieved very easily using inter-process communication. For example a console application can be developed to act as an echo server
namespace EchoServer
{
public class PipeServer
{
public static void Main()
{
var pipeServer = new NamedPipeServerStream(#"Com.MyDomain.EchoServer.PipeServer", PipeDirection.In);
pipeServer.WaitForConnection();
StreamReader reader = new StreamReader(pipeServer);
try
{
int i = 0;
while (i >= 0)
{
i = reader.Read();
if (i >= 0)
{
Console.Write(Convert.ToChar(i));
}
}
}
catch (IOException)
{
//error handling code here
}
finally
{
pipeServer.Close();
}
}
}
}
and then instead of allocating/attaching a console to the current application, the echo server can be started from within the application and Console's output stream can be redirected to write to the pipe server.
class Program
{
private static NamedPipeClientStream _pipeClient;
static void Main(string[] args)
{
//Current application is a Win32 application without any console window
var processStartInfo = new ProcessStartInfo("echoserver.exe");
Process serverProcess = new Process {StartInfo = processStartInfo};
serverProcess.Start();
_pipeClient = new NamedPipeClientStream(".", #"Com.MyDomain.EchoServer.PipeServer", PipeDirection.Out, PipeOptions.None);
_pipeClient.Connect();
StreamWriter writer = new StreamWriter(_pipeClient) {AutoFlush = true};
Console.SetOut(writer);
Console.WriteLine("Testing");
//Do rest of the work.
//Also detect that the server has terminated (serverProcess.HasExited) and then close the _pipeClient
//Also remember to terminate the server process when current process exits, serverProcess.Kill();
while (true)
continue;
}
}
This is just one of the possible solutions. In essence the work around is to allot the console window to its own process so that it can terminate without affecting the parent process.

You can do this by disabling keyboard mouse input by external program called Keyfreez.
you can use it multiple times in your program where no user input required. And if any user input require u can add a process Takskkill /f /IM .
https://www.sordum.org/7921/bluelife-keyfreeze-v1-4-block-keyboard-and-mouse/
Hope this helps all of you

Getting process ID from a shell executed file?

I am making a program for handheld PDAs using .net 2.0 compact framework and I have this one part which I'm not proud of and I was hoping for a more elegant solution.
Basically the problem is another process using my file in this case its Windows Media Player. I start the process by passing the file location to Process.Start but it seems the process returned is short lived and it is spawning another process? So I tried looking up how to get child process information but had some problems with that (i think no processes were being returned for some reason).
So i currently do this dodgy fix
string processName = item.Text;
Process proc = Process.Start(processName, null);
if (!proc.Start())
MessageBox.Show("Failed to start process", "Error", MessageBoxButtons.OK, MessageBoxIcon.Hand, MessageBoxDefaultButton.Button1);
else
{
IntPtr newWindow = IntPtr.Zero;
TimeSpan limit = TimeSpan.FromSeconds(3);
DateTime start = DateTime.Now;
DateTime now = start;
// do while the following:
// window is not null
// window is not ourself
// under 3 seconds
do
{
newWindow = Win32.GetForegroundWindow();
now = DateTime.Now;
// taking too long
if (now - start > limit)
break;
}
while (newWindow == IntPtr.Zero || newWindow == this.Handle);
if (newWindow != IntPtr.Zero && newWindow != this.Handle)
{
uint processID = 0;
if (Win32.GetWindowThreadProcessId(newWindow, out processID) != 0)
{
//const int stringSize = 1024;
//StringBuilder sb = new StringBuilder(1024);
//Win32.GetWindowText(newWindow, sb, stringSize);
m_processes.Add(new ProcessIDWithName(processID, processName));
}
}
}
As you can see I don't like it and it's unreliable however it does work for now (i needed a solution whether it was bad or not).
Why do I need the process ID? Because windows media player is keeping the file open on me and I cannot move/delete the file and therefore I need to kill the process off before I do so. I could do a similar fix with FindWindow but I was thinking more generically as it might not be a media file opened in windows media player.
So basically I would like a better solution if possible!
Also if you wondering why I'm not using a Stopwatch its because it doesn't seem to exist in .net 2.0 cf, also I don't need accuracy to that extent.

There are loads of questions that pop up here.
Why aren't you executing media player itself instead of shellexecuting the name of the target file?
How do you know when the media is done playing in order to close the file?
Why not use the toolhelp APIs to simply enumerate processes instead of the wacky GetForegroundWindow/GetWindowsThreadProcessId shenanigans?
Why aren't you just using the Media Player ActiveX control instead of this kludge so you'd actually have control over things?
If you intend to make this generic for any file (i.e. not just media, but maybe something like the Word viewer, etc) then you're really out of luck and need to rethink whatever it is you're trying to do (you've not told us what you're trying to achieve, only how you['ve decided to implement it). Applications don't normally close in WinMo, they typically just lose focus of get minimized, so you don't really know when a user is "done" with the file.
The application associated with the file may already be running, so terminating it yourself is an unfriendly thing to do.
The target application really is not designed to give you a callback when it's done with any particular file.

I have no experience with PDA programming, bu you can try to use Job objects (see http://msdn.microsoft.com/en-us/library/ms684847.aspx#job_object_functions). With respect of CreateJobObject you can create a new job. Then you create a suspended process and use AssignProcessToJobObject to assign the new process to th job object. Then you can resume the process.
The advantage of job object is, that you can receive full control of all child processes of the job. You can use TerminateJobObject to terminate all processes. If you create creates an I/O completion port to wait for the end of the direct started process and all it's child processes or monitor of all child processes created and much more. If you need I could post some code examples of links to code examples.

.NET (C#) Processes & Adobe Acrobat

Okay, here's the deal...
I have a Windows (XP) program in .NET 2.0 (C#) which allows users to rename a given .pdf file. (The filename is "structurally descriptive", as it lays out simple info about what's in the file itself.) On the program's only form, there is a LinkLabel object which allows the user to open the .pdf itself, so that they can see what they are renaming.
The trick is that, when the user makes the appropriate change(s) and clicks the "Save" button, I want the Acrobat window showing the .pdf to close, the save performed, a "next" file to be retrieved, and a new window to immediately open displaying that next file.
Here's the relevant code snippets:
private void OpenViewer()
{
// NOTE: pdfView is of type Process, in case you're not familiar with
// Process.Start().
pdfView = System.Diagnostics.Process.Start(lnkFile.Links[0].LinkData.ToString());
}
private bool KillViewer()
{
bool result = (pdfView != null);
if (pdfView != null)
{
pdfView.CloseMainWindow();
pdfView.Close();
pdfView.Dispose();
pdfView = null;
GC.Collect();
// Verify that the lock is available before you return, as returning basically says:
// "Yup, the file's available."
bool locked = false;
StreamWriter sw = null;
do
{
try
{
sw = new StreamWriter(new FileStream(lnkFile.Links[0].LinkData.ToString(), FileMode.Open));
locked = false;
}
catch (Exception)
{
locked = true;
}
} while (locked);
sw.Dispose();
}
return result;
}
private void SomeButtonEvent
{
// Record whether a viewer was open in the first place.
bool viewerActive = KillViewer();
PerformFileLockingMethod();
GetNextFile()
if(viewerActive)
{
OpenViewer();
}
}
Notice in KillViewer() that there's basically a lock-grabbing loop to make sure that the program doesn't try to rename the working file until after the pdf viewer has fully released the lock.
The problem is this: sometimes this all works beautifully, and sometimes KillViewer breaks down on the CloseMainWindow() call, with an InvalidOperationException, details = "Process has exited, so the requested information is not available.". This would be fairly straightforward if it weren't for two things...
1: pdfView.HasExited = true
AND
2: The darned pdf viewer is STILL OPEN!!!
How in the world is this possible? Is there a process command I should be using to ensure the window closes? FYI, the program references nothing outside of either System.* namespaces, or internally built class which also ultimately reference only System.*.
Thanks.

Try this instead..
pdfView.Kill();
pdfView.WaitForExit();

After further investigation, I think I've determined what was going on.
I didn't detail workflow details because I couldn't reliably replicate the situation. After further attempts, I found two reliable situations...
Click on the link multiple times and then click save.
Click on the link, close the viewer window, and click save.
In each of these cases, the problem boiled down to the Process pointed to by pdfViewer becoming out of sync with what the user was doing.
If the link was clicked on multiple times, then the active viewer was on a process not connected with pdfViewer's process, hence the seemingly impossible situation detailed above.
If the link was clicked on and the window closed, the pdfViewer variable would remain, leaving a process with HasExited = true.
The take home lesson of all this is as follows: If you're running a separate process from your main user interface, make ABSOLUTELY SURE that you cover every possible situation that could occur with the external process.
For the record, Nick Guerrera deserves points for directing me towards the process IDs. That ultimately solved it.