My application is written using VS2005 and MFC 8.0 and can be
compiled either for the desktop our (our ultimate target) WinCE 5.0.
In addition to the "main" application thread (which is just responsible
for starting/ending threads in the application), we have several other
CWinThread-derived threads--one of which is responsible for creating
the UI for the application. I started wondering where I'd gone wrong
when I noticed that over time as our application ran, it would slow
down until it eventually hung (although it would often recover if given
about 5 minutes to get its whits about it). Eventually, I came up with
the theory that it was somehow my GDI calls that were slowing things
down. It seems I was pretty close, but it's actually the temporary
objects being created with a smattering of whatever::FromHandle() calls
that were growing the threads tempMap to huge sizes.
The upshot of all this is that I noticed that the section of
CWinThread::OnIdle that would be responsible for deleting the temporary
objects was never being called. That noticed, I "solved" the problem
by adding a call to OnIdle(1) every few minutes in the application.
This is just a temporay kludge to prove my point, but I'd like to know
how I should implement a proper solution. Taking a look at MFC's code,
however, I wonder if there's a bug. Let me explain.
Here's what CWinThread::Run() looks like:
// phase1: check to see if we can do idle work
while (bIdle &&
!::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE))
// call OnIdle while in bIdle state
bIdle = FALSE; // assume "no idle" state
// phase2: pump messages while available
// pump message, but quit on WM_QUIT
// reset "no idle" state after pumping "normal" message
bIdle = TRUE;
lIdleCount = 0;
} while (::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL,
So if I'm understanding things correctly, it'll call OnIdle(0) to
start, then increment lIdleCount to 1. Then, if CWinThread::OnIdle had
indicated there was more to be done (and this is the stick point),
it'll call it again with OnIdle(1). HOWEVER, taking a look at
CWinThread::OnIdle() I see this:
if (lCount <= 0)
/* Send WM_IDLEUPDATECMDUI to pMainWnd and all it's children as well
as all registered Frame Windows */
else if (lCount >= 0)
AFX_MODULE_THREAD_STATE* pState =
if (pState->m_nTempMapLock == 0)
// free temp maps, OLE DLLs, etc.
return lCount < 0; // nothing more to do if lCount >= 0
SO... CWinThread::OnIdle(0) will ALWAYS return FALSE to indicate that
it has nothing more to do, despite the fact that the second portion
(which cleans up the TempMaps) has never been executed. Is this a bug?
I ask only because the construct is:
if (lCount <= 0)
else if (lCount >=0)
which doesn't make any sense. Logically, they could just have "else
(lCount > 0)" since the mere presence of "else" and the preceding block
will preclude hitting that section if lCount == 0. Another possibility
for this being a bug would have been if they had intended to NOT have
the else at all (thus an lCount < 0 executes block 1, lCount == 0
executes both, and lCount > 0 only executes block 2). I've digressed a
bit, but I do wonder whether this is a mistake in MFC.
Moving on, I can see that CWinApp rectifies this situation by
overriding OnIdle as follows:
if (lCount <= 0)
// call doc-template idle hook
POSITION pos = NULL;
if (m_pDocManager != NULL)
pos = m_pDocManager->GetFirstDocTemplatePosition();
while (pos != NULL)
CDocTemplate* pTemplate = m_pDocManager->GetNextDocTemplate(pos);
else if (lCount == 1)
return lCount < 1; // more to do if lCount < 1
So, CWinApp's version calls OnIdle for any registered Document
templates, and then says "I have more to do" so that it can call
CWinThread::OnIdle(1) and clean up the temp maps. I'm not sure what
this discovery tells me about how MFC is supposed to be used, but maybe
someone could clarify for me. The following are the options I'm able
to come up with:
1. Applications should always use the main CWinApp-derived thread as
the one that creates any UI elements.
2. CWinThread-derived UI threads that create windows objects are
responsible for making sure the tempMaps get cleaned up on their own.
Could someone tell me if I've completely missed the mark or if any of
this makes sense?
All of the windows (with the exclusion of the "main" application window
which is hidden DO belong to the same thread). I used the terminology a bit
confusingly. MFC refers to any thread with a message queue as a "UI Thread"
(as opposed to a "worker" thread with just a thread function). I this case,
I have several "UI threads" in the MFC/windows sense of the word, but only
ONE of them is actually displaying windows and interacting with the
user/display. My apologies for being confusing.
If you do, let us know the URL for the bug report.
Visual C++ MVP
On 12 May 2006 06:18:36 -0700, "Jay Daniel" <Phaze42...@gmail.com>
Thanks for the reply. The bug submission can be found here:
It's necessarily a bit more terse than my rambling post, but hopefully
conveys the idea. If you think I've missed anything important there, perhaps
you could supplement it with a comment (and/or vote for its importance so
someone at MS actually has a chance of seeing it).
> Thanks for the reply. The bug submission can be found here:
> It's necessarily a bit more terse than my rambling post, but hopefully
>conveys the idea. If you think I've missed anything important there, perhaps
>you could supplement it with a comment (and/or vote for its importance so
>someone at MS actually has a chance of seeing it).
Your summary is fine, and the bug is currently "under review". I did
validate it and vote on it, the former being a prerequisite for the latter.