Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: VC6 C++ C MFC GUI
Hello, I have a console application that works with command line arguments which I don't have its source code, & I want to create a GUI for it to make it easier.
 
My problem is how to make the GUI application calls the console application & handle its output results to display it in a multi-line edit control with a black background & white text in the GUI application !?
 
Help me please
 
NB: Updated.
Posted 29-Mar-12 15:08pm
tomay30001.2K
Edited 29-Mar-12 16:39pm
v2
Comments
johny10151981 at 29-Mar-12 20:54pm
   
Do you know anything about how win32 application works?
tomay3000 at 29-Mar-12 21:40pm
   
yes I do.
SAKryukov at 29-Mar-12 21:14pm
   
How can it add any problems?
--SA
tomay3000 at 29-Mar-12 21:40pm
   
I have updated my question
johny10151981 at 30-Mar-12 0:00am
   
I am not sure if you can do; what I think you want to do
Chandrasekharan P at 30-Mar-12 1:48am
   
if you want your GUI application to call the console applications exe you can use shellexecute()function.
Sergey Chepurin at 30-Mar-12 3:54am
   
Making GUI for an application is a complex task by itself (and you tagged MFC, to make it good looking, i guess). Imagine that your big and good looking MFC GUI application would be calling relatively small console to do some dirty job. This looks weird, at very least.
So, writing the whole application with GUI would be a smart decision.
tomay3000 at 30-Mar-12 13:32pm
   
I have said in my question that I don't have the source code of the console application :(
Sergey Chepurin at 31-Mar-12 3:09am
   
I understand. But, frankly, it even does not deserve a discussion. What is so special this console doing that you can not reproduce in GUI application? The construction you want to implement will have no chance to be called "a program". There will be no error/exception handling, when one part fails (say, console) the other (GUI part) will be still running thinking everything is okay. You cannot use this monster even for your personal needs because you can not be sure that both parts run without errors. Or you are going to implement some weird tracing mechanism? Once again, either create the GUI application including the console's functionality, or just use the console as it is for your needs.
The exception is when the purpose of console is to collect some data and to write it to some data store. Then, GUI application can be designed to get this data from data store, and handle it to present in the user selected form - table, chart, etc. Then the GUI application will be separate program communicating with database only.
tomay3000 at 1-Apr-12 15:05pm
   
You have said "What is so special this console doing that you can not reproduce in GUI application?"
actually it has a very very very special internet tasks. & It is very very very difficult to reproduce it from scratch.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

1) The first part is to call your console application from the UI application - this is easy. For example, in C++ you could call ShellExecute, or CreateProcess with correct command line arguments. I don't know what language/platform you will be using for your UI so I do not elaborate much.
 
2) The second part is inside the UI application - you need to to capture the output from the console application and display it in the edit control of the UI. There are a number of ways to do this, the simplest that comes to mind is to redirect the output of your console app to a text file, and then read that file. To redirect, simply use > redirector, e.g. you should invoke command line such as "ipconfig /all > tmp.txt". Clearly this is the command line that your UI app should be using to invoke the console app. Then, read tmp.txt and analyze/display.
  Permalink  
v2
Comments
tomay3000 at 30-Mar-12 14:04pm
   
Genius.
Seems you have understood my question.
One problem left: How to read the "tmp.txt" from the UI while the console app is still writing to it.
michaelmel at 1-Apr-12 20:23pm
   
After you "kicked" the console application in the UI, you could just wait for file tmp.txt to be created by the console. When UI finished reading from file, delete tmp.txt. Then the whole thing repeats. This will work unless console continuously produces output in an asynchronous manner. If this is the case, you can still read the file, just need to use an appropriate type of file access. I think overlapped I/O should do it.
Francisco T. Chavez at 5-Dec-13 21:44pm
   
What about using a pipe to capture the data from console application? This way you won't have to wait for the console to finish with the temp file.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 3

I hope I understand your issue.
Suppose the name of your console application is TestConsole.exeand it gives the output "ABCDEFGHIJKLM" on executing via command prompt.
Now You need to execute this TestConsole.exe from an application that has a GUI and get the result in your GUI application. If this is the situation then write belwo code in your GUI app
char   pchBuffer[128];
FILE   *pPipe;
if( (pPipe = _popen( "TestConsole", "rt" )) != NULL)
{
    while(fgets(pchBuffer, 128, pPipe))
    {
        // pchBuffer will have the output of console application
        // so write here the code to display this in your edit control
        // or do whatever you want
    }
}
  Permalink  
Comments
tomay3000 at 30-Mar-12 14:17pm
   
You are awesome.
You have completely understood my question.
 
I will try it.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 4

  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 6

Please see it[^] Smile | :)
 
Your parent process could be covered by a GUI application
and its ReadFromPipe(..) function could transfer the child's text into a box.
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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 System.Diagnostics.Process.Run with redirected streams StandardInput, StandardOutput and, just in case, StandardError. 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[^],
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardoutput.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 (Process.WaitForExit) 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 StandardInput, 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
  Permalink  
v2
Comments
tomay3000 at 29-Mar-12 21:41pm
   
I think that you don't understand me.
I have updated my question.
SAKryukov at 30-Mar-12 1:46am
   
Certainly, but after your clarification of the question (and only after that), the question became quite clear.
Please see the new answer above, after [EDIT]. This is a complete recipe for what you can do.
--SA
tomay3000 at 30-Mar-12 13:45pm
   
Damn, The links you provided to me concerns .Net Framework, but I work with MFC.
SAKryukov at 30-Mar-12 18:21pm
   
Oh, I'm sorry!
 
With C++, this is pretty much the same, but via CreateProcess.
Please see:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
 
See also related methods on this page.
--SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Zoltán Zörgő 265
1 /\jmot 205
2 CHill60 145
3 Peter Leow 145
4 CPallini 135
0 Sergey Alexandrovich Kryukov 9,363
1 OriginalGriff 6,881
2 Peter Leow 4,577
3 Zoltán Zörgő 4,184
4 CHill60 2,892


Advertise | Privacy | Mobile
Web02 | 2.8.150129.1 | Last Updated 6 Dec 2013
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100