I use and have used AllocConsole and FreeConole quite a bit in my Windows
programs so thought I might chime in on this subject. I find consoles in
GUI apps particularly useful for debugging. I believe you need to use
'cprintf' defined in conio.h to print to the console created with
AllocConole.
Here is a little C++ code I typically used to provide console access. I
compile it with cl.exe (Microsoft's C/C++ compiler) so I don't know if there
will be any problems with gcc. It is fairly simple code so I couldn't
imagine there would be. There is also code in there for a generic global
log forwarder which allows you to attach logs with various trace level, and
forwards call to the appropriate loggers. That code is somewhat inefficient
and still needs work.
The class of interest for console logging is creatively named 'console_log'.
You can then use it as a standard output buffer in statements like:
console_log clog;
clog << "Hello world!" << std::endl.
Your could also replace the C++ standard cout underlying string buffer with
the console_log's and use cout as normal. At the very least it can server
an example of console logging. If you do wish to incorporate this code
anywhere I only ask that you keep my name in the comment.
Hope you find this useful.
- Joshua
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Christopher
Faylor
Sent: Sunday, October 21, 2001 12:08 PM
To: [EMAIL PROTECTED]
Subject: Re: console IO in GUI apps
On Sun, Oct 21, 2001 at 01:09:28AM -0700, Augustus Saunders wrote:
>Christopher Fayler wrote:
>>FWIW, this is exact problem plagues the Windows version of insight (aka
>>gdb). The only solution we ever came up with was either to call
>>AllocConsole when we needed to write something to a console -- which
>>sucks for when you're starting the program via the console, or to build
>>the program as a console app -- which means that you always get a
>>flashing black box if you double click on a gdb icon.
>>
>>It *looks* like the MSVC program somehow manages to do what we want
>>here since it seems to exist as both a console and a windows app but I
>>was never able to figure out how to do what it did. Most likely, I am
>>just misinterpreting what it does do.
>
>
>Chris, if I understand you correctly, then you want the (GUI)
>application to detect whether or not it was launched from an existing
>shell and then to use the shell it was run from for its console.
>Otherwise, you want to spawn a new console. IIRC, when an application
>is launched from a console, then you can just use standard in and
>standard out and it works as if by magic.
Have you tried this?
If you link a program with -mwindows and do a "printf" in the program,
nothing shows up on the console.
If you do an "AllocConsole" prior to the printf then a new console window
opens up and your message will be displayed there.
>I would also mention that there is an AttachConsole where you can use
>an already existing console, you just have to know the console owner's
>PID.
The MSDN documentation indicates that AttachConsole is available on
Windows XP only. It's not a generic solution.
>One last thing I tripped over, if things don't "just work":
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/pr
othred_4uus.asp
>
>This shows how you can reroute a child process's standard in and out to
>pipes, which you can then do whatever you want with. Not saying you
>want to do this, but it might give you some other ideas.
cgf
winlog.cpp
winlog.h
