Question : Program freezes when AfxGetApp()->PumpMessage( ) is called
I’m still fairly new to MFC programming and especially multithreading, but my multithreaded application is now freezing when PumpMessage is called.
Here is the code where it freezes:
while (currtime GetConnected())
//processes normal messages
while ( ::PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE ) )
if ( !AfxGetApp()->PumpMessage( ) )
m_Time = CTime::GetCurrentTime();
currtime = m_Time.GetSecond() + m_Time.GetMinute() * 60 + m_Time.GetHour() * 60 * 60;
I traced the code through, using the debugger, and it froze when it was at the GetMessage Function inside of PumpMessage.
This code is actually contained within the main thread of the program. It is in a class which has a global instance in the hopes that all of the threads can access it and use its functions without error (does this work?).
In other areas of my program I used messages to communicate between threads, but I thought I could share this class by making it global.
This function (Open) is called by a function in a class other than the main one, does that make a difference?
It actually used to work fine, and still does sometimes. This error only appeared after I fixed a different one (of course).
If anyone has any suggestions or can tell me some more about multithreading I’d appreciate it.
Solution: Program freezes when AfxGetApp()->PumpMessage( ) is called
>>/*This makes it freeze when I uncomment it and comment out the while loop above*/
>>ret_code = SetConnected(1);
Just guessing, based on experience with the CInternetConnection class, but that hard-coded “1” is probably an application-defined session ID. When you instantiate secondary connections, you will need to use 2,3,… etc
Jennifer, I can point out little things like the above, there are just too many things going on for me to really be much help with this question. There is the IPWorks class that I don’t have and all of the rest of the infrastructure of your program. There are unusual things like your CEdit-derived class that runs on its own thread,that are simply impossible to debug remotely.
I *highly* recommend that you create a new project that does just the minimum — make a single connection with a single thread. When that is working, see if you can add a secondary connection on a single thread — even if all of the output is garbled in one window, you’ll be able to debug without worrying about multiple-threading issues.
When everything is rock-solid, try adding in some multi-threading logic.