Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to output to the command Line in MFC

673 views
Skip to first unread message

Al

unread,
Jan 21, 2003, 3:05:09 PM1/21/03
to

Hi all,

There is my problem, i converted a MFC application to be
able to call it by the command line (ex. dos box). I added
a module that parse the commande line and skip the doModal
to output a specific string. The problem is that i cant
output the string to the command line (where i called the
MFC application).

I need to output to the command line because i use a
script to launch the MFC application and im waiting for
the output string to continue the scrip.

How know how to output to the command line from a MFC
application.

Thx ,


JJS

unread,
Jan 21, 2003, 3:35:15 PM1/21/03
to

Al <med...@hotmail.com> a écrit dans le message :
085001c2c188$66152510$cef82ecf@TK2MSFTNGXA08...
>
> Hi all,

>
> How know how to output to the command line from a MFC
> application.
>
GetCommandLine()
Jack

Al

unread,
Jan 21, 2003, 3:40:19 PM1/21/03
to

Thx for answering,

I dont need to get the command line information
(getCommandLine()) ... What i need is to be able to output
to the dos box like the command printf or cout. The
problem is that this command doesnt work because the
application is a MFC application and not a console one.

Any idea how to output from a MFC application to the
command line ?

Thx again


Kobi Ben Tzvi

unread,
Jan 21, 2003, 5:19:51 PM1/21/03
to
Hello Al,

Look for console functions in MSDN.
For example to create console, you need to call AllocConsole. For writing
WriteConsole etc.

--
Regards,
Kobi Ben Tzvi


"Al" <med...@hotmail.com> wrote in message
news:085001c2c188$66152510$cef82ecf@TK2MSFTNGXA08...

Al

unread,
Jan 21, 2003, 5:26:14 PM1/21/03
to

But can i write in the console that called the MFC
application ? (i dont want to create a new one, i need to
output in the one that called the MFC application)

thx

>.
>

Kobi Ben Tzvi

unread,
Jan 21, 2003, 5:52:05 PM1/21/03
to
Hello again Al,

Take a look at AttachConsole API function.

--
Regards,
Kobi Ben Tzvi


"Al" <med...@hotmail.com> wrote in message

news:09e001c2c19c$1bd22110$cef82ecf@TK2MSFTNGXA08...

CheckAbdoul

unread,
Jan 21, 2003, 6:05:32 PM1/21/03
to
See if the following link helps you in anyway.

http://www.codeguru.com/console/index.shtml

--
Cheers
Check Abdoul [ VC++ MVP ]
-----------------------------------

"Al" <med...@hotmail.com> wrote in message
news:09e001c2c19c$1bd22110$cef82ecf@TK2MSFTNGXA08...
>

Kobi Ben Tzvi

unread,
Jan 21, 2003, 6:43:34 PM1/21/03
to
Hi Rob,

Actually also 2000
.
But if 9x matters, then there is no way. Unless the application wants to
print some short message and exit. For example if application is called with
"/?" parameter and it wants to print the switches that it supports and
exit(or continue to run but have no access to console) its possible. Its the
same trick that MS used in MSDev. If you ever noticed there are 2 files in
bin directory, msdev.com(console app) and msdev.exe (note: com extension
have higher priority so they get launched before .exe). msdev.com checks if
"/?" was supplied if yes then it prints short usage message and quits,
otherwise it launches msdev.exe which is the actual IDE.

Another trick can be writing console application which runs another gui
application, and they use some kind of IPC which will allow GUI app to
request from console app writing into console.

--
Regards,
Kobi Ben Tzvi


"Rob" <r...@dptechnology.com> wrote in message
news:#LYb4SawCHA.2604@TK2MSFTNGP12...
> I hope you realize that AttachConsole is only supported in Windows XP.
>
> Rob
>
>
> "Kobi Ben Tzvi" <tsum...@hotmail.comREMOVETHIS> wrote in message
> news:uaaax#ZwCHA.2796@TK2MSFTNGP12...

Al

unread,
Jan 21, 2003, 6:38:36 PM1/21/03
to
Thx for the link,

I will go try the tips there,

Al

>.
>

Rob

unread,
Jan 21, 2003, 6:24:50 PM1/21/03
to
What you want to do is use console I/O. Take a look at the documentation
for cout.

The command line interpreter has a special symbol what is called "piping".
You can pipe the output of one program to the input of another program by
using the | operator.

A classic example of this is the "more.exe" program, ie.

C:\>dir /s | more

That would send the output from the dir command to the "more.exe" program so
that it can pause on each page.

Rob


"Al" <med...@hotmail.com> wrote in message

news:085001c2c188$66152510$cef82ecf@TK2MSFTNGXA08...

Rob

unread,
Jan 21, 2003, 6:28:21 PM1/21/03
to
I hope you realize that AttachConsole is only supported in Windows XP.

Rob


"Kobi Ben Tzvi" <tsum...@hotmail.comREMOVETHIS> wrote in message
news:uaaax#ZwCHA.2796@TK2MSFTNGP12...

Kobi Ben Tzvi

unread,
Jan 21, 2003, 6:34:11 PM1/21/03
to
Hello Rob,

> That would send the output from the dir command to the "more.exe" program
so
> that it can pause on each page.

Yes but "more.exe" will get input only after dir terminates, they don't run
same time. I don't think this is Als case, he is developing GUI application
and just wants to be able also to write to console.

--
Regards,
Kobi Ben Tzvi

"Rob" <r...@dptechnology.com> wrote in message

news:eKno6QawCHA.1676@TK2MSFTNGP10...

Rob

unread,
Jan 21, 2003, 7:55:23 PM1/21/03
to
Al,

Are you trying to get rid of the user interface all together? If so, you can
make the following changes to convert your MFC application to a console
application.

1) In the compiler settings, remove the _WINDOWS define and replace that
with _CONSOLE

2) In the linkage settings, change your subsystem to "console". You'll see
a command line switch as follows "/subsystem:windows". Change that switch
to "/subsystem:console"

You'll now need to define a startup function. Use the following as an
example.

int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
int nRetCode = 0;

// initialize MFC and print and error on failure
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
{
// TODO: change error code to suit your needs
cerr << _T("Fatal Error: MFC initialization failed") << endl;
nRetCode = 1;
}
else
{
// TODO: code your application's behavior here.
}

return nRetCode;
}

This will now forgoe any initialization that used to happen in your GUI's
InitInstance or OnInitDialog. You should move that initialization to the
function _tmain.

Rob


"Al" <med...@hotmail.com> wrote in message
news:085001c2c188$66152510$cef82ecf@TK2MSFTNGXA08...

Rob

unread,
Jan 21, 2003, 7:59:34 PM1/21/03
to
Kobi,

Actually I think you should read the original posting again. Al is
converting an existing MFC application to a console program.

> > > There is my problem, i converted a MFC application to be
> > > able to call it by the command line (ex. dos box). I added
> > > a module that parse the commande line and skip the doModal
> > > to output a specific string. The problem is that i cant

He specifically states that he got rid of the call to "DoModal". I'm
guessing that it was a Dialog based MFC app.

Rob


"Kobi Ben Tzvi" <tsum...@hotmail.comREMOVETHIS> wrote in message

news:ux1ZSWawCHA.2796@TK2MSFTNGP12...

Al

unread,
Jan 21, 2003, 9:51:41 PM1/21/03
to
In fact,

I didnt converted my MFC application to a console
application, i just modified my MFC application to be able
to execute it from the commond line.

Sorry if you didnt understant what i was trying to
explain, im not very good in english.

My MFC application take in input, in a MDI interface, a
hexa number and convert this number to a string that i
output in a MessageBox.

I changed my MFC application to :

1- parse the command line
2- If i found arguments , i skip the doModal
3- And then, find the string,
4- and finaly, i want to be able to print it to the
console who called the application.


Thx again,

>.
>

Al

unread,
Jan 21, 2003, 10:04:35 PM1/21/03
to
Thx for answering,

Actually, i dont want to get rid of the UI, i just want
to be able to execute the MFC in 2 different way:

Normal way: User interface by MFC
Second way: By the command line, because i need to
redirect the output to a perl script.

Note: I understant that when you call a MFC executable
from a command line (dos prompt) that windows will detach
the MFC from the command line because the MFC is a stand
alone application and the command line is free to do any
others operation.

Thx again

>.
>

Joseph M. Newcomer

unread,
Jan 22, 2003, 1:26:01 AM1/22/03
to
You don't "output to the command line". The command line is an input parameter which is a
string.

You also can't write to the console that launched the program because Windows applications
don't have consoles. And it is not clear why it would make sense to try to find one.
Windows applications are not console applications.

Launch the app using the command to do an asynchronous launch, e.g.,
start myprog
instead of just saying
myprog
which is a synchronous launch.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

Joseph M. Newcomer

unread,
Jan 22, 2003, 1:29:46 AM1/22/03
to
There is no concept of "two ways to launch". There is exactly one call, CreateProcess,
that is used to create all processes. If you type a program name to the command shell, it
calls CreateProcess. If you double-click something in the explorer or desktop, it calls
CreateProcess (ShellExecute is a high-level wrapper around CreateProcess; there is exactly
ONE way to create a process in Windows, CreateProcess. Everything else is cosmetic). If it
type of the app is console, its stdin, stdout, and stderr are linked to the console that
launched it. If it is a Windows app, stdin, stdout, and stderr have no meaning. That's it.
joe

Joseph M. Newcomer [MVP]

Joseph M. Newcomer

unread,
Jan 22, 2003, 1:40:39 AM1/22/03
to
There is no such concept. An MFC application cannot determine how it was launched. You
keep asking the same question over and over, and the answer is that MFC applications don't
have consoles, can't inherit consoles (although with a certain amount of effort you can
create a new one and attach it), and there is no API to ask "where did this app get
launched?" because that is a meaningless question to ask. A console app can't ask the
question, either. A console app gets a console (or inherits one) because the Console
Subsystem in Windows is invoked when a console app is launched. It sets everything up and
calls some very-low-level APIs to deal with the console attachment. Windows is not MS-DOS.
It is worth pointing out that in Win16 you couldn't launch a GUI app from a command line
at all. They fixed this in Win32, but essentially, a GUI app is a GUI app is a GUI app,
and GUI apps don't have consoles.
joe

Joseph M. Newcomer [MVP]

Joseph M. Newcomer

unread,
Jan 22, 2003, 1:44:55 AM1/22/03
to
Well, the docs say only XP and .NET server. And you have to have the process ID of the
console app to attach to.

The problem is that he has built an idea based on a faulty premise. There are a number of
other possible solutions depending on what the .bat file is trying to do (for example,
writing a program that does what the .bat file does, writing a file that shells out
commands, wriing a simple script interpreter, etc.) but without knowning what the purpose
of using a .bat file is and what the file does, and what degrees of flexibility are
required, it is hard to suggest a viable solution.
joe

On Wed, 22 Jan 2003 01:43:34 +0200, "Kobi Ben Tzvi" <tsum...@hotmail.comREMOVETHIS>
wrote:

>Hi Rob,
>
>Actually also 2000
>.
>But if 9x matters, then there is no way. Unless the application wants to
>print some short message and exit. For example if application is called with
>"/?" parameter and it wants to print the switches that it supports and
>exit(or continue to run but have no access to console) its possible. Its the
>same trick that MS used in MSDev. If you ever noticed there are 2 files in
>bin directory, msdev.com(console app) and msdev.exe (note: com extension
>have higher priority so they get launched before .exe). msdev.com checks if
>"/?" was supplied if yes then it prints short usage message and quits,
>otherwise it launches msdev.exe which is the actual IDE.
>
>Another trick can be writing console application which runs another gui
>application, and they use some kind of IPC which will allow GUI app to
>request from console app writing into console.

Joseph M. Newcomer [MVP]

Joseph M. Newcomer

unread,
Jan 22, 2003, 1:49:49 AM1/22/03
to
No, we understood the question perfectly. But outside XP and .NET server, what you want is
impossible. And on those, it is merely incredibly difficult (since there is no effective
procedure defined to locate your console process to get its process ID)
joe

Joseph M. Newcomer [MVP]

Al

unread,
Jan 22, 2003, 9:48:40 AM1/22/03
to

First of all,

Thank all for answering my question. I will explain again
my problem and describe the solutions available to it, i
hope this resume will help other people who have the same
kind of problem or type of application to do.

####The problem:
Part 1:
I have a MFC application (windows application) who is
principal work is to convert a number to a description
string :
example--> input window (edit box): 0x0348500
output window(message box):imagetype=COLOR+BGR32+ALPHA

Part 2:
I have a script(perl) that parse an output text file that
containt some number, like above (0x00348500), that i want
to convert to a description string. My idea, was to simply
call the MFC application from the perl script (dos prompt)
and capture from the script the output string generated by
the MFC application. To do that, i changed my MFC
application to:
1- read input parameters (CCommandLineInfo)
2- skip the DoModal part of the MFC application if i found
parameter (ex. -0x0238500)
3- Call the same code that convert the number to the
description string (Dont want duplicate code). This is the
reason why i dont want to rewrite a console application.
4- Output the description string to the console(dos prompt)
*** PROBLEM: Its impossible to write to the console that
lauched the MFC application, because the MFC application
is a windowed application and dont know and dont see the
console application. *****

####The concept behind the problem:
I understant that a windows application can't write to the
console that launched the program because Windows
applications don't have consoles, and dont know anything
about the console that launched it. I also understand that
a windowed application dont have any stdout, stderr and
stdin. I also understant the concept that after the
command prompt (console) have launched the MFC
application, that the command prompt is free now to do any
operation (ex. like a dir command). Then its normal that
the MFC application cant write to the command prompt,
because this one is maybe already using is stdout for an
other command.


####The solutions:
solution1 : I can change the MFC application to unlink the
application code (engine part) from the user interface of
the MFC application, and therefor, use it (wihtout code
duplication) in an other console application.

This solution is clean, but need refactoring of the MFC
application

solution2 : Modifie the MFC application to use the Win32
function AttachConsole(). This function attaches the
calling process to the console of the specified process.
After attached to the console, i suppose that i will have
access to the stdout, stderr and stdin of the console, but
im not sure ? (i didnt try this solution, because its a
unusual solution, and didnt know if i will have access to
the stdout )

solution3 : Change the MFC application like specified in
the part 2 of the problem section of this email, and write
the description string to a file in the temp directory.
Now i can write a batch file that:
1- lauch my MFC application with the paramater
2- Read the output file (who containt my description
string)
3- echo the string to the stdout
4- Delete the temporay file created by the MFC application
5- et voila!!!
Code of the batch file GetDescriptionString.bat:
GetDescriptionString.exe -0x00348500 fileName
type fileName
del fileName

This is the end of this beautifull story: "how to output
to the command line from a windows application."

If you have others solution, reply this post.
Thx again all for the answer. Be safe, i code well :)

Al

>.
>

Al

unread,
Jan 22, 2003, 10:02:06 AM1/22/03
to
Oups, sorry for my mistake !!!

I didnt want to wrote : "Be safe, i code well :)"
but instead : Be safe, and code well :) hehehe!!!

A+

>.
>

Rob

unread,
Jan 23, 2003, 1:41:49 PM1/23/03
to

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:bjes2vc9heglp2k45...@4ax.com...

> There is no such concept. An MFC application cannot determine how it was
launched. You
> keep asking the same question over and over, and the answer is that MFC
applications don't

You're absolutely wrong in this case. An "MFC" application can get the
console from which it was launched. However a "windows" application cannot.
There's a very distinct difference. Just because you use the MFC framework,
that does not preclude you from developing a console application.

Rob

unread,
Jan 23, 2003, 1:49:21 PM1/23/03
to
Al,

Is it necessary to use the same executable for both purposes? Would it be
sufficient to be able to build a console and a GUI version of the same
project?

I can only assume at this point that the reason you're approaching the
problem in this fashion is because you do not wish to have two different
code bases. With just some slight changes in the profile you can have a
"Win32 - GUI" build and a "Win32 - Console" build. This way you could
rebuild the GUI or the console executable without having to worry about
differences in the code base.

Rob

"Al" <med...@hotmail.com> wrote in message

news:09c101c2c227$3a9ff5f0$d4f82ecf@TK2MSFTNGXA11...

Rob

unread,
Jan 23, 2003, 2:04:27 PM1/23/03
to
Al,

Although given your problem I don't believe you need this, I figured I'd
post the sample code to stuff the keyboard buffer for the console.

----------------------------------------------------------------------------
--------------
void StuffInput( char *lpszInput )
{
ASSERT(lpszInput);
if (lpszInput == NULL) return;

INPUT_RECORD ir;
memset(&ir,0,sizeof(INPUT_RECORD));

ir.EventType = KEY_EVENT;
ir.Event.KeyEvent.bKeyDown = TRUE;
ir.Event.KeyEvent.wRepeatCount = 1;

HANDLE hInput = ::GetStdHandle(STD_INPUT_HANDLE);
if ( hInput != INVALID_HANDLE_VALUE )
{
for ( char *pCh = lpszInput; *pCh; pCh++ )
{
ir.Event.KeyEvent.uChar.AsciiChar = *pCh;

DWORD dwWritten = 0;
::WriteConsoleInput(hInput,&ir,1,&dwWritten);
ASSERT(dwWritten == 1);
}
}
}
----------------------------------------------------------------------------
----------------

Again, for what you're trying to accomplish, you should use the object
"cout". But, if for some reason you really want to stuff the keyboard
buffer, this function will serve that purpose.

Rob


"Rob" <r...@dptechnology.com> wrote in message

news:uxw7RAxwCHA.1620@TK2MSFTNGP11...

Joseph M. Newcomer

unread,
Jan 24, 2003, 5:04:10 AM1/24/03
to
Yes, you are correct. However, MFC doesn't give all that much advantage outside GUI apps,
so I tend to ignore that corner case. So if you substitute "GUI App" (which is the more
correct term) then I am still correct, and since he was tyring to do a GUI app, my
statements are still correct.
joe

Rob

unread,
Jan 24, 2003, 1:18:29 PM1/24/03
to
Joe,

If that makes you sleep easier at night then please continue to believe
that. However I've written many console apps that have a user interface.
Trust me, MFC does help. Why do you think they now let you create a console
project with MFC support? Yes, I know it's partially because of the use of
utility classes like CString and the template library. However the MFC
windowing support is very as well.

Rob

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message

news:eq323vo50nr3vt7eu...@4ax.com...

Al

unread,
Jan 27, 2003, 8:41:15 AM1/27/03
to
Thx for the tips ...

Your first solution is good for me, because i can use 2
executable, but dont want duplicate code. I will try this
solution today.

thx again,

Al

>.
>

0 new messages