OnOK() takes long time and never ends. devenv.exe *32 in task manager had to be killed to end the process
Tuesday, May 08, 2012 6:02 AM
I created an MFC application to read data from a list of .txt files and save the required output into a .csv file. I am using ifstream/ofstream for data in and out. Everything works fine, all the files are opening correctly and closing correctly and the new .csv file is being created properly. Towards the end of the routine, I am giving OnOK() to finish the process and it is here everything gets stalled.
I have a feeling that the program is trying to clear the file buffers that I used to read the data in and write data out into the files. But I was of the impression that filepointer.close() should clear the buffer.
Once the input and output files are closed the dialog disappears but the background process keeps on running. I had to kill devenv.exe *32 process associated with my MFC app to end the process.
Any idea where the problem could be? If I am not clear in explaining my problem, I can post the code.
- Edited by RadhikaC Friday, May 11, 2012 10:35 AM
Tuesday, May 08, 2012 1:16 PMIs the "background process" you refer to a secondary thread? It you have created a secondary thread then you also have to make sure it has exited before you can close the window. Also, it would not be valid to call OnOK from the secondary thread. Please provide more information about the thread-related aspects of your code.
Tuesday, May 08, 2012 7:29 PM
I haven't created any secondary thread, sorry about my wording. When I execute the MFC dialog application in Debug mode, the file I/O happens fine and the new file I wanted is getting created. But when I set a break point to see where the application is taking long time without finishing, I understood that everything else (File I/O, file opening and closing) is getting completed but when the execution reaches OnOK() the dialog disappears but the Output window shows something is executing and the green triangle (use to execute the MFC application) still remains grey. The whole application stays in this state even after 25-30 mins.
Hope I made it clear, if not I can post the code.
Tuesday, May 08, 2012 10:31 PM
Can you try breaking execution during that state? To break execution, press the "F12" key in visual studio while debugging. Then look at the callstack and see if you see anything from your code. You could also load symbols from the Microsoft symbol servers and take a guess as to what may be happening by looking at the callstack.
Also, you can possibly try to use a profiling tool if you you have one.
Wednesday, May 09, 2012 12:37 AM
If you use Cancel is behavior the same?
Is your dialog modeless by any chance?
OnOK and OnCancel default implementation calls EndDialog.
EndDialog does not dismiss modeless dialog, it hides dialog and breaks dialog’s message loop.
Since modeless uses App message loop, after OK or CANCEL dialog is invisible but message loop is still active.
Override OnOK and OnCancel and call DestroyWindow in both, do not call the base class.
See if this rectifies your problem.
Wednesday, May 09, 2012 6:05 AM
DestroyWindow() doesn't seem to solve the problem.
I tried breaking the execution and look at the call stack. The call stack breaks at msvcr90d.dll. I tried executing and breaking several times and the call stack output is at msvcr90d.dll.
msvcr90d.dll!_VCrtDbgReportA(int nRptType=1927872512, const char * szFile=0x72e910f6, int nLine=20480, const char * szModule=0x0040003e, const char * szFormat=0x005b7e70, char * arglist=0x00180016) Line 435 + 0x18 bytes C
File where the execution stops:
I am also pasting the code if this helps
###################### CODE BEGIN ############################################
// TODO: Add your control notification handler code here
CString Inputpathname, Outputpathname, Sourcepathname;
double temp =0;
int len =0;
string SubID ="";
Sourcepathname = "C:/TextFiles.txt";
Outputpathname = "C:/AA2AdaptDurationsTest.csv";
getline(Sourcefile, filename, '\n');
Inputpathname = "C:/";
Inputpathname += filename.c_str();
while ( !Inputfile.eof())
//Reading from source file and Writing into destination file
else cout << "Unable to open Inputfile";
} //end of while loop for Sourcefile
bool flag =DestroyWindow(); //OnOK() was replaced by DestroyWindow()
####################### CODE END #################################################
Thursday, May 10, 2012 6:11 AM
Thursday, May 10, 2012 8:45 AM
No luck with PostQuitMessag(WM_QUIT);
Thursday, May 10, 2012 5:26 PM
Did you try any profiling?
AMD CodeAnalyst has a free app that you can try. Easy to use.
Thursday, May 10, 2012 11:13 PM
If you are out of while(!Sourcefile.eof()) and press OK and application does not exit, there is something else going on.
You are out of the loop; otherwise your app would be unresponsive.
Does it also do it when you click on CANCEL?
You still did not answer my question: is this modal or modeless dialog? I also presume that this is a dialog based application.
If dialog is modal, do not use DestroyWindow; this only applies to modeless dialog.
If dialog is modal, after dismissing dialog are you returning FALSE from app’s InitInstance?
Would it be possible to post entire project so it can be downloaded and debugged?
Friday, May 11, 2012 5:56 AM
It is the same with OnCancel() too.
My MFC app is a dialog based application and is a modal dialog. I just trying to see what happens with DestroyWindow(), but obviously it did not work. How can I post the entire project. Sorry about asking this, I was looking to send it as an attachement, but couldn't find a way to do it. Please let me know. Should I have to use 'Insert Code Block' ?
Friday, May 11, 2012 11:44 AM
Can you please confirm, the control is coming to the following line.
bool flag =DestroyWindow(); //OnOK() was replaced by DestroyWindow()
Thanks and Regards Selvam http://www15.brinkster.com/selvamselvam/
Friday, May 11, 2012 12:07 PMTry http://www.mediafire.com/. After uploading, you will receive link to share gor downloading.
Please also include text file you are reading. Do not zip debug/release folders and ncb, suo files
Friday, May 11, 2012 1:52 PM
Here is the share link
I have uploaded the main text file from which I am reading file names and also couple of text files and the output file (AA2AdaptDurations.csv).
Hope this helps.
Yes, the control does come to DestroyWindow();/OnOK(); whichever is included.
Saturday, May 12, 2012 11:16 AM
I am not able to download files; site is asking me to install some toolbar. I did it on one of my VPC (to isolate it) and still the error message is: Download not permitted, for some files.
Could you please remove all files and use WinZip, RAR or some popular compression software, zip your project and upload just one file, making sure it is shared?
Do not include: Debug folder, .ncb, .aps, .user and.suo files.
Saturday, May 12, 2012 11:29 AM
I forgot to mention:
Once you upload files please use a given link to test download.
Monday, May 14, 2012 5:46 AM
Sorry, there was some problem with my network yesterday. Below is the fresh link with a RAR file, and the link works. I made sure that I did not include Debug folder, .ncb,.aps and .user files. My project doesn't have a .suo file but I have a .sln which I included! If this is an issue let me know, I can delete the .sln and upload the RAR again.
Tuesday, May 15, 2012 2:39 AMGot it. Missing res folder but this is not a problem.
Is late I am going to dig in tomorrow. From the first look it seems like your while loops are either never broken out of or take a lot of time.
Tuesday, May 15, 2012 5:45 AM
Thanks. The routine I am having the problem with is OnBnClickedAa2adt(), this is associated with the button 'AA2-AdaptDuration Times' in the dialog. The while loops do break and the control comes down to the last line of the routine, anyway I'll wait to hear from you.
Tuesday, May 15, 2012 11:05 PM
Well, I found several things that contributed to the behavior you experienced.
In debug build, VS outputs all memory leaks. Since you have not released memory after allocating Mode:
char* Mode = new char[mode.size() + 1]; each time your code is looping, it took some time to output all information, hence delat. If you gave enough time, eventually VS would have come to life.
Another thing that takes time and puts application int a frozen like state are tight while loops you use to process files. All controls are not functional, since loop takes all CPU time.
Attached file contains several changes:
Addresses memory allocatio/release problem
I added worker threads to process data and making controls functional.
Added synchronization allowing thread to be stopped if user eant to close dialog without finishing.
Added mechanism allowing toggling controls enable state depending if thread processing files is running.
Couple of oother tings you should be aware of:
Your application is compiled as UNICODE app, while in the code you are using ASCI mixed with UNICODE. That should not be a case and you should consider writing a code that is consistent and builds without errors for both configurations (ASCII and UNICODE).
You are using MFC. My advice would be to be consistent and if you can do not use standard libraries. It is nothing wrong In doing so but consistency is a key.
When you declare arrays, I would suggest to define array size and use it instead of hard coded numbers. It prevents from weird things happening when you decide to change an array size. If you have to do it in many places yor code is error prone. Using defined value, allows you to change the value in one place.
And the last but not the least: you have filenames anpaths harcoded. Thst I a nono even for the test projects; it creates a habbit. User should have ability to choose folders for file operations.
Ling to download dialog files:
- Marked As Answer by RadhikaC Thursday, May 17, 2012 11:20 AM
Thursday, May 17, 2012 11:19 AM
Thanks so much. I'll note down all your suggestions and be careful with my future programming. The new code sent by you works perfectly well. It takes a minute or so for execution, which is agreeable as it has to read more than 30 files. I was waiting for more than 45mins with my previous code, but it would still not finish.
Thank you once again for the solution as well as programming suggestions.
Thursday, May 17, 2012 7:31 PMYou are very welcome, glad to be of help.