PeekMessage hanging
-
I have been using a modeless dialog for indicating the progress of a task. In the dialog is a CProgressCtrl, and a cancel button. I have recently added a CListCtrl as well. Everything works fine as long as you do not move the dialog, or click in the list control. Once you do this, things start to get wierd. Usually, there is a 2-3 second delay when clicking on something, or moving the window. During this delay, nothing is happening with the task that the dialog is showing the progress of. It should be continuing on, but nothing happens. The screen does not draw correctly either. Each time I manually break, the stack points to my function that is pumping messages (it gets called periodically during the task). The PeekMessage seems to be "stuck" for some reason. Again, this only happens if the dialog is moved, or when clicking on a control within the dialog. Any ideas on why this may be happening? Any work-arounds?
while (::PeekMessage (&msg, NULL, 0,0, PM_NOREMOVE)) { if (pbrcv != NULL && msg.message == WM_MYMSG1){ *pbrcv = true; } if (!AfxGetApp()->PumpMessage()) { ::PostQuitMessage(0); return false; } } // // Simulate the framework's idle processing mechanism. // LONG lIdle = 0; while (AfxGetApp()->OnIdle (lIdle++)) ; }Thanks, DaveQ -
I have been using a modeless dialog for indicating the progress of a task. In the dialog is a CProgressCtrl, and a cancel button. I have recently added a CListCtrl as well. Everything works fine as long as you do not move the dialog, or click in the list control. Once you do this, things start to get wierd. Usually, there is a 2-3 second delay when clicking on something, or moving the window. During this delay, nothing is happening with the task that the dialog is showing the progress of. It should be continuing on, but nothing happens. The screen does not draw correctly either. Each time I manually break, the stack points to my function that is pumping messages (it gets called periodically during the task). The PeekMessage seems to be "stuck" for some reason. Again, this only happens if the dialog is moved, or when clicking on a control within the dialog. Any ideas on why this may be happening? Any work-arounds?
while (::PeekMessage (&msg, NULL, 0,0, PM_NOREMOVE)) { if (pbrcv != NULL && msg.message == WM_MYMSG1){ *pbrcv = true; } if (!AfxGetApp()->PumpMessage()) { ::PostQuitMessage(0); return false; } } // // Simulate the framework's idle processing mechanism. // LONG lIdle = 0; while (AfxGetApp()->OnIdle (lIdle++)) ; }Thanks, DaveQI assume you have a single-threaded program. When you click on one of the controls on the modeless dialog, it is not receiving enough of the CPU to carry out what needs to be done (e.g, paint). When it does get a timeslice, things probably appear "jumpy." The PeekMessage() solution you have employed is an antiquated and largely unused 16-bit Windows solution (but still used because it is "well known"). It's bad for several reasons. The most important one is that it puts, in the time-critical main loop, a function whose overhead is substantial. Another problem is, since there is a modeless dialog active, there is no IsDialogMessage() call there to handle it. Go with a worker thread.
-
I assume you have a single-threaded program. When you click on one of the controls on the modeless dialog, it is not receiving enough of the CPU to carry out what needs to be done (e.g, paint). When it does get a timeslice, things probably appear "jumpy." The PeekMessage() solution you have employed is an antiquated and largely unused 16-bit Windows solution (but still used because it is "well known"). It's bad for several reasons. The most important one is that it puts, in the time-critical main loop, a function whose overhead is substantial. Another problem is, since there is a modeless dialog active, there is no IsDialogMessage() call there to handle it. Go with a worker thread.
Thank you for replying. Unfortunately, the worker thread isn't something I'm going to be able to do. It's difficult to explain why. I did try putting the dialog in a GUI thread, but got the same result. I think what may be happening is the message that helps keep the task running properly is getting "eaten" by something?? The PeekMessage loop that I showed earlier is there to keep the GUI alive, but the filter is set to read all messages. I thought that the task message (call it WM_USER + 100) would be left alone since I specified PM_NOREMOVE, but it is acting as if the message is not being left in the queue. I may have to do something cheesy like prevent the window from being moved if I can't find the problem. Thanks for your help.