Friday, December 07, 2007

Capture the output of console process and display on your GUI application

I use GBAK.EXE to perform backup and restore operation of Firebird database in my GUI application design. The reason I use GBAK instead of firebird service manager is I can perform remote backup and restore operation via TCP/IP network without transferring the backup file to firebird server first. However, as GBAK is a console utility, It display the output to STDOUT or STDERR. There is no easy way to capture the output while the console process is running. We need to invoke windows API to perform the task. We may use CreatePipe and CreateProcess to redirect the STDxxx handles and use ReadFile to capture the output in our GUI application. Here are some references that may helps:
  1. Microsoft knowledge base: How to spawn console processes with redirected standard handles
  2. Borland newsgroup: Catch console output in real time
There is a drawback using windows native API aproach. As stated in microsoft knowledge base:
Child processes that use such C run-time functions as printf() and fprintf() can behave poorly when redirected. The C run-time functions maintain separate IO buffers. When redirected, these buffers might not be flushed immediately after each IO call. As a result, the output to the redirection pipe of a printf() call or the input from a getch() call is not flushed immediately and delays, sometimes-infinite delays occur. This problem is avoided if the child process flushes the IO buffers after each call to a C run-time IO function. Only the child process can flush its C run-time IO buffers. A process can flush its C run-time IO buffers by calling the fflush() function.
I face this problem if I use GBAK to perform a lengthy backup and restore operation via this approach. The GUI application always stop half way in unforeseen point although it will finish the operation at last. There isn't any response from the ReadFile when it hang some where. I suspect it was due the GBAK utility written didn't perform flush as described.

No comments: