Hello!
I am making an application that processes multiple files (typically > 500) through a command prompt call. The way I start the command prompt app is by looping using a call to CreateProcess for each file that is to be processed. It works fine, except that I somehow loose 'connection' to my app so that 1: Windows says that the app. is 'Not Responding'
2: The Cprogress bar in my app is not updated before all files have been processed, even though there is a CreateProcess call and a Cprogress.StepIt() from the app for each file that needs processing.
I somehow suspect that the CPU gets swamped...
I do not want that Windows starts to say that my app is 'not responding' and I want my Cprogress dialog bar to update according to the number of files that are progressed through.
I wonder if multithreading is the OK way to go instead of just kicking of series of CreateProcess calls? Maybe my CreateProcess is not ending correctly? It seems as if my app is 'not regaining control' before very late. The app never crashes though.
My CreateProcess code is listed below, maybe there can be a problem with it, or maybe I should do things in a different way? My app basicaly works as it never crashes, but with above mentioned problems it is NOT a pro solution... Help much appreciated:-)
BR's
Gustav

void CMultiFilerDlg::ProcessFile(CString pdfFile)
{
int i=0;
DWORD ProcID;
// Open file in text mode:
STARTUPINFO si;
PROCESS_INFORMATION pi;
char cmdArgs[2052];
ProcID=GetCurrentProcessId();
si.wShowWindow=SW_HIDE;

*cmdArgs=NULL;
sprintf(cmdArgs,"%s", pdfFile.GetBuffer(0));

ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );

if( !CreateProcess( "C:\\Program Files (x86)\\MyCommandApp.exe",
cmdArgs, // Command line.
NULL,
NULL,
FALSE,
CREATE_NO_WINDOW,
NULL,
NULL,
&pi ) )
{
int ERR=1;
}

// Wait until child process exits.
WaitForSingleObject( pi.hProcess, INFINITE );

// Close process and thread handles.
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );




}