|
Below is the code the control is not coming after dlg.DoModal();
if (!CreateProcess(NULL, /* No module name (use command line). */
theApp.m_lpCmdLine, /* Command line. */
NULL, /* Process handle not inheritable. */
NULL, /* Thread handle not inheritable. */
FALSE, /* Set handle inheritance to FALSE. */
CREATE_NO_WINDOW, /* Do not display console window */
NULL, /* Use parent's environment block. */
NULL, /* Use parent's starting directory. */
&si, /* Pointer to STARTUPINFO structure. */
&pi)) /* Pointer to PROCESS_INFORMATION structure. */
status = GetLastError();
CProgressActivityDlg dlg;
m_pMainWnd = &dlg;
//INT_PTR nResponse =
dlg.DoModal();
//if (nResponse == IDOK)
//{
// TODO: Place code here to handle when the dialog is
// dismissed with OK
//}
//else if (nResponse == IDCANCEL)
//{
// TODO: Place code here to handle when the dialog is
// dismissed with Cancel
//}
MessageBox(NULL, _T("Before loop"), _T("Test"), MB_OK);
WaitForSingleObject(pi.hProcess, INFINITE);
MessageBox(NULL, _T("Out of loop"), _T("Test"), MB_OK);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
PostMessageW(dlg.GetSafeHwnd(), WM_CLOSE ,0, 0);
// Since the dialog has been closed, return FALSE so that we exit the
// application, rather than start the application's message pump.
AfxGetMainWnd()->PostMessage(WM_CLOSE, 0, 0);
return FALSE;
|
|
|
|
|
So the problem is to get the control out of dlg.DoModal(); somehow is it possible to do so usisng the modal dialog I have created. what is the alternative
|
|
|
|
|
tom groezer wrote: the problem is to get the control out of dlg.DoModal()
You'd have to send/post a message to the dialog. When the dialog responds to
the message, it can call CDialog::EndDialog().
The problem is you need another thread to post the message - or the message has to
come from the other process.
An alternative is to use a modeless dialog, but if you sit and wait on the UI thread
for the other process to end, your dialog will become unresponsive.
Best bet....use a worker thread to wait on the other process 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi there.
I've got a bit of a weird one here. I'm writing a pair of compression/decompression programs for a varsity assignment and there is something odd happening in the transmission of integers. Basically, the spec is that they must be stored big endian so I wrote these:
bool writeintbigendian ( FILE * file, int number )<br />
{<br />
unsigned char *c = ( unsigned char * ) &number;<br />
<br />
for ( short i = sizeof ( int ) - 1; i > -1; i-- )<br />
{<br />
if ( fputc ( c[i], file ) ==EOF )<br />
return false;<br />
}<br />
<br />
return true;<br />
};<br />
<br />
int readintbigendian ( FILE * file )<br />
{<br />
int readInt = 0;<br />
unsigned char * c = ( unsigned char * ) &readInt;<br />
<br />
for ( short i = sizeof ( int )-1; i > -1; i--)<br />
{<br />
c[i] = (unsigned char) fgetc(file); <br />
}<br />
<br />
return readInt;<br />
};
Now there is a dictionary of ints that are written out using writeintbigendian and then the ints are read in using readintbigendian to reconstruct it. The process reads in like 42 ints and then bombs out where the value of -230 was supposed to have been written. The reason being because -1 is read instead of -230.
To narrow down the problem, I stopped the debugger in the write section to find out what it was writing. The arguments to fputc are the following in order:
-230 = |255|255|255|26|
when it comes to reading it out using fgetc it ends up with
-1 = |255|255|255|255|
Clearly either the read function is reading the last byte in incorrectly or the write is writing it incorrectly but I can't figure out which. It's certainly not a synching issue either because the previous 42 values all get transmitted fine and there are no other intermediate steps when reading or writing. It's literally going through a for loop on both sides calling the respective functions. Obviously, I'd like to avoid delving into binary formats of files here.
|
|
|
|
|
OK, I've closed the file after it writes the last byte and analysed the binary. It definitely writes |255|255|255|26|. Which means fgetc in readintbigendian is at fault. Is there some Windows sideffect I'm unaware of?
|
|
|
|
|
I don't think its issue with read, you just try to open file write -230 close it, open read and close and check, may be you are not reading from correct offset.
|
|
|
|
|
Yes, that would be the obvious conclusion but the fact is 42 items previous to that are being read correctly, so the offsets are clearly correctly synched.
|
|
|
|
|
Here is the code where the writing is done.
for(unsigned int i = 0; i < dictionary[0]; i++)<br />
{<br />
if(!writeintbigendian ( out, dictionary[i+1] ))<br />
{<br />
status = FAILED;<br />
return status;<br />
}<br />
}<br />
...and the reading.
unsigned int dict_size = readintbigendian(in);<br />
int * dictionary = new int[dict_size+1];<br />
dictionary[0] = dict_size;<br />
<br />
for(unsigned int i = 1; i <= dict_size; i++)<br />
{<br />
dictionary[i] = readintbigendian(in);<br />
}
|
|
|
|
|
Klempie wrote: unsigned int dict_size = readintbigendian(in);
in your code for writting you didn't shown writting dictionary size.
Klempie wrote: if(!writeintbigendian ( out, dictionary[i+1] ))
write start from 1;
may be you are writting it, I still don't believe problem in file read if you properly used it, if you not writting the dictionary size and read it, the fgetc(file); return EOF at end of file at that time, EOF value is -1 you get it instead of -230; you are not checking error status of fgetc, check it.
the following code for me works well,
#include <stdio.h>
FILE *fpWrite = NULL, *fpRead = NULL;
int iArrDataWrite[] = { 1,2,3,4,5,6,7,8,9,10,
11,12,13,14,15,16,17,18,19,20,
21,22,23,24,25,26,27,28,29,30,
31,32,33,34,35,36,37,38,39,40,
41,42<big>,-230</big>,44,45,46,47,48,49,50,
51,52,53,54,55,56,57,58,59,60
};
#define DATA_SIZE (sizeof(iArrDataWrite)/sizeof (iArrDataWrite[0]))
int iArrDataRead[DATA_SIZE] = {0};
int main( void )
{
int numclosed;
if((fpWrite = fopen( "bigEndianData.bin", "wb" )) == NULL )
{
printf( "The file 'bigEndianData.bin' was not opened for writting\n" );
return 0;
}
else
{
printf( "The file 'bigEndianData.bin' was opened for writting\n" );
printf( "Writting to file\n" );
for (int i = 0; i < DATA_SIZE; i++)
{
printf( "%d,", iArrDataWrite[i]);
if (((i + 1) % 10) == 0) printf( "\n");
writeintbigendian(fpWrite, iArrDataWrite[i]);
}
fclose( fpWrite);
fpWrite = NULL;
}
if((fpRead = fopen( "bigEndianData.bin", "rb" )) == NULL )
{
printf( "The file 'bigEndianData.bin' was not opened for reading\n" );
return 0;
}
else
{
printf( "The file 'bigEndianData.bin' was opened for reading\n" );
printf( "reading from file\n" );
for (int i = 0; i < DATA_SIZE; i++)
{
iArrDataRead[i] = readintbigendian(fpRead);
printf( "%d,", iArrDataRead[i]);
if (((i + 1) % 10) == 0) printf( "\n");
}
fclose( fpRead);
fpRead = NULL;
}
return 0;
}
modified on Friday, May 9, 2008 10:13 AM
|
|
|
|
|
OK. It looks as if it is reading EOF but the binary format of the file has 1A (26) as the last byte.
Firstly, the app is reading 255 which is the non-2s complement of -1 which is EOF. Why isn't it reading the 26 at all?
Second, what if there exists valid data equalling 255 that is not supposed to be the EOF? how do you tell the filestream to read it as such and keep the stream open?
|
|
|
|
|
first of all you didn't answer whether you are writting the dictionary file size as per your code it is not. EOF is fgetc returns to indicate error you need to check the error status using functions like feof or ferror to determine error, eof or useful data.
|
|
|
|
|
Yes the dictionary size is being written to the first element of the dictionary.
Second, I have used feof to determine that it is reading the last byte as (EOF==-1). What I am saying is, the binary format of the input file shows that it is 26 not -1. What I want to know is why it is reading the EOF character and not the one which is clearly in the file.
|
|
|
|
|
Problem solved. I opened it using "r" and not "rb". Apparently the substitute character 0x1A is used as EOF in text files.
|
|
|
|
|
I was going to ask you how you opened it, i overrated you initially i didn't asked about binary mode.
|
|
|
|
|
but the dictionary size write and feof is not there in your code. Without more code i cannot say more, how you initialise, close, seek the file before read.
|
|
|
|
|
No Raj, it's cool. It's working now. I know what the problem was. I opened it to read it as a text file. The EOF character for text streams is 0x1A which equals 26 (I'm guessing this applies to Windows systems only). So obviously when the stream reads 0x1A it returns -1 as EOF to the application. The key is to fopen with "rb" and not only "r". Obviously then you are reliant on yourself to make sure your app doesn't read over the end of your file. In my application EOF is irrelevant because I use dimensions to keep track of where I am. That's why it doesn't appear in my code. In fact, for binary files it would appear that EOF is only useful for binary data which does not include the EOF value. Anyway, it is working now, so thank you for all your help.
|
|
|
|
|
I already shown in my code how i opened to read file with "rb"
|
|
|
|
|
just a guess. wouldn't flushing the stream help you in this regard ?
|
|
|
|
|
toxcct, you may be onto something here.
I've done this:
for(unsigned int i = 1; i <= dict_size; i++)<br />
{<br />
dictionary[i] = readintbigendian(in);<br />
if(i%60==30)
fflush(in);<br />
}
Interestingly, it now starts reading incorrectly from the 30th value onwards. So flushing is the cause of it rather than the solution. I'm no expert on the internals of stream mechanics, so any suggestions on how to restructure my stream access would be highly appreciated.
|
|
|
|
|
hum, but are you sure you want to write this ?
for(unsigned int i = 1; i <= dict_size; i++)
instead of this :
for(unsigned int i = 0; i < dict_size; i++)
because arrays are 0-based.
but i'm not sure this is related though
|
|
|
|
|
No it isn't. The reason it starts at 1 is cos I store the length of the dictioary array in the first element.
|
|
|
|
|
arg, but that's awful !!! lol.
really, you should consider revising this bad habit 
for the flushing stuff, i have no much idea unfortunately
|
|
|
|
|
well it's not a habit lol. I just did it that way cos it's quick and easy. It's a varsity project so I'm not too bothered about it being elegant. :p
|
|
|
|
|
flushing is to commit the data to disk which the OS keeps in memory for optimisation, "The commit-to-disk feature of the run-time library lets you ensure that critical data is written directly to disk rather than to the operating-system buffers", this may not be the issue in your case.
if you want to use call flush after the write loop to ensure data is written directly to disk.
|
|
|
|
|
That is the same habit that Pascal strings (and BSTRs) have. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
