Re: Problems with a secondary message pump
On Wed, 6 May 2009 14:54:02 -0700, Rob <Rob@discussions.microsoft.com>
wrote:
So, what should I pass into MWFMO's dwWakeMask parameter? Would passing in
zero get it to do what I want (process the messages, but only wait on the
process)?
I don't see any indication in the documentation that would be useful. Why
wouldn't you use QS_ALLINPUT? That's what I used in my example code.
Also, you mentioned something in your earlier post about giving temporary
MFC objects some permanence to prevent OnIdle processing from freeing them
up. How do I go about doing that? (My code is in a member function of a
CWinApp-derived class and, so, has no direct access to the current window or
its resources.)
I would need to see how you're creating the objects that are going bad. It
was just a guess that OnIdle is freeing them, but freeing temporary MFC
objects is one of the things OnIdle does. For example, if you're using
CWnd::FromHandle to obtain a CWnd* for an HWND that isn't associated with a
"permanent" MFC object (examples of "permanent" MFC objects include a
window for which you called CWnd::Create or bound to a dialog member
variable), you will get a pointer to a temporary CWnd that will be deleted
during the next round of idle processing. These temporary objects are
intended to be used without ever dropping back into the message (and hence
OnIdle) loop. The exception to this rule concerns modal dialogs, whose
message loops do not perform this processing for reasons that have never
been clear to me. Perhaps MS thought it would be common to save GetDlgItem
pointers instead of binding control variables to HWNDs, but the former is
very "SDK old school" and very bad MFC practice.
--
Doug Harrison
Visual C++ MVP