There is no such thing as "command line application". This is because absolutely any application can get whatever appears in the command line and analyze it. If does not really related to threads or UI.
First of all, in C/C++ applications, you can use entry points with different signatures (for, in fact, please see the link below). Two of them accept command line parameters. When such signatures are used, the runtime system takes the command line argument which OS passes to the application, parse them properly and passes as arguments of the entry point function. Here they are:
int main(int argc, char **argv)
int main(int argc, char *argv)
You should use this data in your application, according to the application semantics you design.
For more detail, please see:http://en.wikipedia.org/wiki/Main_function#C_and_C.2B.2B
As to the threads, you should use the regular precautions when passing data between threads. You need to know it anyway; there is nothing specific to passing command line arguments.
[EDIT: an answer after OP clarification of the question]
This is a totally different story. You should not call it "command line application". This is probably a "console application". You can solve this problem.
You can run the console application using
with redirected streams
and, just in case,
. Please see:http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx
You can find code samples with redirection here:http://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardinput.aspx
You don't have to read the output of your console application to the end. You could read it line by line (or some other portion, depending on application) and process it on the fly. This is a blocking call, it will keep a thread in a wait state when data from the console application is not ready. Therefore, you should do it in a separate thread. You also should wait for the process termination (
) in a separate thread. It majorly depends on what kind of console application is that. If could be prolonged process, so you will need to feed it data permanently until you decide to terminate it, and process the data coming form this child process on the fly. This would be a kind of simulation of the interactive user by your UI process.
If this is a short-leaving process and if you want to run the whole process repeatedly, this is much simpler scenario. If this thing in really fast, you don't even need to use separate thread (but in general case this is always better). You might not even feed data to it through
, because in such application it is usually possible to pass all data in the very beginning in a command line; in other words, such process can be used non-interactively.—SA