Ah, I think I know what is happening.
The file stream is not required to keep the actual disk file up-to-date with the fstream's state at all times. It can wait until it is convenient to write data to the file.
So it looks to me like there is a race condition occurring between the two applications to access the file data.
You can force it to synchronize the disk file and the fstream's data buffer by using the
flush function/manipulator, and for FILE*s use
fflush().
So, when the button is clicked, the following should happen:
- Make sure to fflush before calling ShellExecute().
- Remember that ShellExecute starts the indicated process but does not wait for it to terminate. You must use one of the wait functions to wait for the program to terminate. For example:
bool ExecTheChildProc()
{
// Both files should be flushed or closed before calling this function
// Execute the child process...
HINSTANCE hChild = ShellExecute( ... );
// ...and wait for it to terminate
// (You can specify a specific number of milliseconds to wait
// before returning so that you can get control back periodically
// and make sure your application doesn't freeze.)
DWORD result;
while (true) switch (WaitForSingleObject( hChild, 500 ))
{
case WAIT_OBJECT_0:
// Success. The child is terminated
// and the files are ready to be read.
return true;
case WAIT_TIMEOUT:
// Half a second has passed.
// Make sure the application stays responsive.
ProcessMessages();
break;
default:
// Something has gone wrong.
return false;
}
return false; // keep the compiler happy
}
- Read the result.
Call the ExecTheChildProc() when the button is pressed (or put the code in your button event method).
The
ProcessMessages() function is not defined by MFC. However,
you can find it here.
If you don't expect the child to take much time, you can skip the loop and everything and just say:
return WaitForSingleObject( hChild, INFINITE ) == WAIT_OBJECT_0;
That's a zero on the end of the WAIT_OBJECT_0 macro.
Hope this helps.