Asked By JoeO
20-Nov-09 07:16 PM
I have got a dialog that under certain circumstances (when a radio
button is pressed), needs to create another thread and wait for it to
finish. While it is waiting, it processes the windows message loop
(PeekMessage with PM_NOREMOVE) and sends all messages down through the
app via AfxGetApp()->PumpMessage().
Let's call the radio button ID_DO_WORK.
If the user clicks ID_DO WORK with the mouse to start this chain of
events, every thing works fine. However if the user uses keyboard
shortcuts to "press" the radio button, I get into this hideous
nightmare. I keep getting the same WM_COMMAND with ID_DO_WORK over
and over again -- the same one I am already processing.
I cannot figure out why a keyboard activation causes this while a
mouse click does not. Should I be ignoring certain messages in my
loop? Should I be calling something besides PumpMessage().
Here is the relevant code:
// NOW WAIT ON A SINGLE MESSAGE
dwExitCode = MsgWaitForMultipleObjects (1,
(LPHANDLE)
&hThread,
false,
dwRemainingTimeOutMs,
QS_ALLEVENTS |
QS_ALLINPUT);
// NOW TEST THE EXIT CODE
if (dwExitCode == WAIT_OBJECT_0)
{
// THREAD HAS SUCCESSFULLY COMPLETED
bExitWaitLoop = true;
// THREAD GOT SIGNALLED (EXITED) OK
iRetCode = (int)dwExitCode;
}
else if (dwExitCode == WAIT_OBJECT_0 + 1)
{
// AT LEAST ONE WINDOWS MESSAGE IS WAITING TO BE
PROCESSED
while (::PeekMessage (&rxMsg, NULL, 0, 0,
PM_NOREMOVE))
{
TRACE(_T("Work thread got message 0x%X\n"),
rxMsg.message);
// SEND THE MESSAGE BACK TO THE MAIN APP
if (!AfxGetApp ()->PumpMessage ())
{
// GUARD AGAINST IT NOT BEING A QUIT MESSAGE!
// FORCE PROGRAM TO QUIT
bExitWaitLoop = true;
}
}
}
else
{
// ASSUME A TIMEOUT HERE
bExitWaitLoop = true;
iRetCode = CWT_THREAD_TIMEDOUT;
}