UI threads

[ccasey1]

How do I transfer control of painting the main frame to a secondary UI thread while the first (main) thread is tied up in a loop, where it cannot respond to WM_PAINT messages?

Thanks,
Chris

You can do something like this:

CClientDC dc(AfxGetMainWnd());
dc.TextOut(0, 0, "Test");

[ingrilli]

Check out the MFC HWND-CWnd* maps (CWnd::FromHandle and CWnd::FromHandlePermanent)... If I was you I'd rather have the 1ary thread handle the message queue, and the 2ary doing whatever work -- the 1ary thread can always gracefully handle the termination of 2ary thread). I would do this because when the 2ary thread tries to dereference HWND's to their actual CWnd-derived class types, it will most likely fail. In fact, MFC matains a thread local HWND-CWnd* map, hence if a 2ary thread tries to get the object for an HWND created in another thread, it won't find, but it will generate a generic CWnd for it (Or a CTempWnd in VC6) which is probably not what your actual window is. So a CEdit created in the 1ary thread, referenced by HWND in a 2ary thread, can only be referenced as a generic CWnd (or CTempWnd), probably not what you wanted. What you will get in your running program is a lot of access violations (all caught in your default win proc), probably some asserts, hopefully not GPF's, but definetly nothing on your screen.

Also check out another cool new thing -- Fibers. Jeffrey Ricther has a very good sample on the net (check out MSDN on Fibers), and you'll find a way to avoid creating threads alltogether, altough you will need to swap from one fiber to another, but it definetly simplyfies MFC threading. Jeffrey's example shows you an example of performing lengthy calculations while the UI processing is idle, but for the program still to be responsive -- sounds just like your app -- you want the UI to remain responsive (painting), but you still want to do some work while the user is not using your CPU cycles.