VC> Any idea what, in the wxWidgets system, could be bombarding the
VC> application's message queue with WM_NULL?
It looks like wxApp::WakeUpIdle() is being called from somewhere. Putting
a breakpoint in it should be enough to see where is it called from.
Good luck,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
SetEvent(hStopEvent); // thread exits upon this
DWORD dw;
HANDLE ahEvent[1] = {hThread};
while (true)
{
dw = MsgWaitForMultipleObjects(1, ahEvent, FALSE, INFINITE,
QS_ALLINPUT);
if (dw == WAIT_OBJECT_0)
break;
else if (dwRetVal == WAIT_ABANDONED_0)
{
break;
}
else if (dwRetVal == WAIT_TIMEOUT)
::wxSafeYield(); // perhaps needs special handling
else
::wxSafeYield();
}
I discovere that:
1. MWFMO keeps returning *immediately* on *neither*
WAIT_OBJECT_0, nor WAIT_ABANDONED_0, nor WAIT_TIMEOUT.
Instead, it returns on QS_ALLINPUT
2. This, of course, lands on the call to ::wxSafeYield();
3. Stepping through ::wxSafeYield() reveals that it also
keeps returning *immediately*, after processing WM_NULL.
The problem is... this poor message queue keeps being bombarded with
WM_NULL messages (or is it the same WM_NULL all this time?) and the
result is that this loop never breaks.
Actually, the loop does eventually break (on WAIT_OBJECT_0) - but only
after 5 minutes (which I believe is Windows XP's mechanism to kill
rougue or hung threads).
Any idea what, in the wxWidgets system, could be bombarding the
application's message queue with WM_NULL?
Or, if it doesn't bombard the queue at all, why is WM_NULL never
handled by ::wxSafeYield() ?
I looked at the source code for wxApp::Yield() and noticed that there
is special handling for WM_QUIT. However, I couldn't find anything
special about WM_NULL.
Any ideas or suggestions as to how to solve the mystery?
Thanks,
Victor
P.S. I am using wxMSW-2.6.3 on Windows XP SP2 (VC++ 2005 EE)