Intercepting PRINT*,'Hello World' messages in C++

[rfvujm]

Hello,

Not sure this is the very right place to ask this question, however can't think of any better... :)

I have a static library written in Fortran, linked to C++ application that calls its subroutines. I'd like to intercept messages generated in the lib by:

PRINT *,'Hello World'

in C++ app (say, to save them in CString). Any ideas?

Thanks a lot,
Mario

[TimP]

You might consider replacing the PRINT with a C++ function call to include the string in your C++ output stream.

[Steven_L_Intel1]

You can't intercept a Fortran WRITE like that. Tim's suggestion is probably best.

[Jugoslav_Dujic]

I think that Mario wanted something else -- to suppress the output to console and instead log it to an internal buffer, but without changing the Fortran source code.

The answer is to redirect the output to... something... using SetStdHandle(STD_OUTPUT_HANDLE, hSomething) API. Note, however, that it will redirect all console output of your application: you cannot separate Fortran and C++ output. If your C++ code is a GUI, that won't be a problem, so read on.

hSomething is a handle of a streamable device: disk file, memory-mapped file, or a pipe. Now, pick your choice:

1. Disk file (returned by CreateFile) is the simplest , but it's basically one-way street: if you have to read it in the program, you must reopen the file every time. Also, you cannot know when it is updated by the Fortran lib.
2. Memory-mapped file (see CreateFile/CreateFileMapping/MapViewOfFile APIs) will redirect the output into a memory-mapped file, and you can read that memory from C++ side. However, it is asynchronous, and you can't know when it was updated, as above.
3. Pipe (CreatePipe) reading is synchronous, so you can do something with the output as soon as it's written. However, the call to ReadFile(hPipe) is blocking (and it will block your UI while you wait), so you must listen to it in a separate thread. See http://support.microsoft.com/kb/190351 for an example using pipe-based interprocess communication (the example is an overkill for you, because you need to do this within one process).

[OP1]

Mario, Jugoslav,

This is something I am very interested in as well. I have a code which, when an error condition is met, will issue a message on the console, this being done in a library for which I do not have the code. In other words, my own code has no idea when calling the library function if the call was legit or not; being able to read the console and look for the error message would be fantastic.

If you can come up with a simple example demonstrating this message-capture approach it would be of great help for me as well!!

Thanks a lot for this very useful tidbit of information. I am glad I stumbled across this thread by chance!

Olivier

[Jugoslav_Dujic]

Hi Olivier,
Your message had slipped under my radar (ah, that nice unchangeable default of 10 threads per Forum page). I'm rather busy this week, but I'll try to assemble a sample later. Feel free to remind me (by replying to this thread) if I forget...

[jimdempseyatthecove]

Olivier,

Here is my suggestion.

First determine which C runtime library functions are being called to write your error output (it may not be what you first assume). This may be one or two functions in the library.

Second, slightly modify the C runtime library functionssuch that they observe a flag and take one of two paths: one for inyour code, one for in DLL code.

Third, create a shell function for the DLL library calls in your code whereby it sets the routing flag first, calls the DLL function andon return clears the routing flag.

The other suggestion of using a Pipe (and seperate monitoring thread) is good provided that your code does not also issue print/write/... that you do not wish to end up in the pipe. (Note, the solution to that would be to add the filter flag as I suggest above, and in which case why have the pipe).

Jim Dempsey