damages when executing console from MFC

[lahom]

hi
i created MFC dialog based application and in an event of a button i want to execute a C++ console application .
i've tried severl functions such as shellexecute and create process ....but
it executes it but then return the wrong answers .....where if i run the application console by itself ....it gave me the right calculations ....
please i neeeed this so bad....my project is supposed to be delieverd in satureday MORNING(one day left)
pleeeeeease
thank u all

[Duoas]

What do you mean by 'it returns the wrong answers'? How are you returning data from the console application?

[lahom]

by database
from console to database
from database to MFC

[Duoas]

That still isn't anywhere near enough information. What DB are you using? What commands are you using to access it? What software library are you using to interface with it?

[lahom]

ok ...
to be more clear ....what my program does is :
1- open acertain 2 files in 2 editboxes(through a browse buttons).
2-the content of the editboxes is saved in 2 files called file1, file2 .
3-then i press a button where it should execute a console applicatin to compare between file1 and file2 .
the problem :
if i did the last 3 steps its doesnot give the right answer all the time ...AND if i run the console application with the previous file1, file2 it doesnot give the right answer either.
BUT
if i run the console application elsewhere with the original names of the files chosen in the browse button , it gave me the right answer ..
so i guess the problem in files or what????
HELP

[lahom]

ok
this is the code for the browse button:

//**BROWSE DIALOG 1**//
//******************************************************//
char strFilter[] = "CPP Files (*.cpp)|*.cpp|All Files (*.*)|*.*||";

CFileDialog m_ldFile(TRUE, ".cpp", NULL, 0, strFilter);

if (m_ldFile.DoModal() == IDOK) //Start File dlg box
{
	m_sFileName=m_ldFile.GetPathName(); //Get file name

	FILE *fp=fopen(m_sFileName,"rb"); //Open file for reading

	if( !fp )
	{
	 DWORD dwError = GetLastError();
	 CString sError;
	 sError.Format("Open Error: %d, %d\n", errno, dwError);
	 AfxMessageBox(sError);
	 return;
	}
	// Get the file size

	int nFileLong;
	{
	 fseek(fp,0,SEEK_END); //Go to file end 
	 nFileLong=ftell(fp); //Get length
	 fseek(fp,0,SEEK_SET); //Go to file start 
	}


	char* sText = new char[nFileLong+1]; //reserve string space

	int i=fread(sText,1,nFileLong,fp); //Read the characters

	sText[i]=0; //Set string terminating null

	fclose(fp); //Close file 

	// Make a copy

	{
	// FILE *file1 = fopen("C:\\Program Files\\C++ Clone Detector\\file1.txt","w+"); //Create txt file for saving editbox content

	 if( !file1 )
	 {
		DWORD dwError = GetLastError();
		CString sError;
	    sError.Format("Copy Error: %d, %d\n", errno, dwError);
		AfxMessageBox(sError);
	 }
	 /*else
	 {
	 fwrite(sText,1,nFileLong,file1); //print the content of the editbox into the file
	 fclose(file1); //Close file2
	 }
	 */
	}

	m_EDIT1=sText; //Put text in Edit box's variable

	fwrite(sText,1,nFileLong,file1); //print the content of the editbox into the file
	 fclose(file1); //Close file2

	delete [] sText;

	UpdateData(FALSE); //Force data to go to Edit control
}

the same goes for file2.
file1 and file2 are declared as:

file1 = fopen("C:\\Program Files\\C++ Clone Detector\\file1.txt","w+");   //Create txt file for saving editbox content
file2 = fopen("C:\\Program Files\\C++ Clone Detector\\file2.txt","w+");   //Create txt file for saving editbox content

and when i press the button :

ShellExecute(this->m_hWnd,"open","C:\\Program Files\\C++ Clone Detector\\Debug\\proto1.exe","","", SW_HIDE );

and in the console application the file1 , file2 are declared :

ifstream infile ("C:\\Program Files\\C++ Clone Detector\\file1.txt");
ifstream infile2 ("C:\\Program Files\\C++ Clone Detector\\file2.txt");

[Duoas]

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:

1. Make sure to fflush before calling ShellExecute().
2. 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
     }

3. 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.