App doesn't shut down propperly
-
Hey guys My app has a mem leak which results from ExitInstance() not being called when I terminate the program. I have traced into MFC and descovered that in the THRDCORE.cpp file, the following code is causing ExitInstance() to NOT be called. ============================================================== // phase2: pump messages while available do { // pump message, but quit on WM_QUIT if (!PumpMessage()) return ExitInstance(); ============================================================== Does anybody know what some of causes of pumpMessage() to return true?? Thanks George George W Software Developer www.zsystems.ca
-
Hey guys My app has a mem leak which results from ExitInstance() not being called when I terminate the program. I have traced into MFC and descovered that in the THRDCORE.cpp file, the following code is causing ExitInstance() to NOT be called. ============================================================== // phase2: pump messages while available do { // pump message, but quit on WM_QUIT if (!PumpMessage()) return ExitInstance(); ============================================================== Does anybody know what some of causes of pumpMessage() to return true?? Thanks George George W Software Developer www.zsystems.ca
If your message pump processes a WM_QUIT, then the GetMessage returns false. Per MSDN --- "What Is WM_QUIT? Normal message-processing loops in an application's WinMain routine usually exit when the GetMessage function returns a FALSE value. Internally, if GetMessage is about to return a WM_QUIT message, it returns FALSE instead of TRUE even though the message returned in the MSG structure (a WM_QUIT message) is valid. The only time GetMessage will ever return a FALSE value is when it is returning a WM_QUIT message. Conversely, PeekMessage returns WM_QUIT messages as it would any other message. Applications that use PeekMessage in their main message-processing loop must explicitly look for the WM_QUIT message. The PostQuitMessage function does not actually post a WM_QUIT message to the application's task queue. Instead, it sets a flag that is tested inside GetMessage and PeekMessage. WM_QUIT is returned when GetMessage or PeekMessage detects that this flag is set and no other messages or events are pending for the application."
-
If your message pump processes a WM_QUIT, then the GetMessage returns false. Per MSDN --- "What Is WM_QUIT? Normal message-processing loops in an application's WinMain routine usually exit when the GetMessage function returns a FALSE value. Internally, if GetMessage is about to return a WM_QUIT message, it returns FALSE instead of TRUE even though the message returned in the MSG structure (a WM_QUIT message) is valid. The only time GetMessage will ever return a FALSE value is when it is returning a WM_QUIT message. Conversely, PeekMessage returns WM_QUIT messages as it would any other message. Applications that use PeekMessage in their main message-processing loop must explicitly look for the WM_QUIT message. The PostQuitMessage function does not actually post a WM_QUIT message to the application's task queue. Instead, it sets a flag that is tested inside GetMessage and PeekMessage. WM_QUIT is returned when GetMessage or PeekMessage detects that this flag is set and no other messages or events are pending for the application."
That is pure GOLD! Thank you....I have been struggling with this problem for a while. I knew exactly where to look as soon as I read that. Problem fixed! Thanks again IGeorgeI George W Software Developer www.zsystems.ca