We help IT Professionals succeed at work.


softbee asked
Medium Priority
Last Modified: 2013-11-20
I am working in Windows VS2003 and my app has to do with hardware security interfaces. I am NOT using .NET.
My problem started when I decided to multi-thread an automation out-of-process server. The server has a GUI and the GUI was moved to the 2nd CWinThread. Since then, repeated hits of ShowWindow( SW_HIDE ) etc does not work on the 2nd dialog ( the one in the additional CWinThread ) but will activate the 1st dialog, which now purely exists to assist in generating "blocking calls" from the client.

The other methods in the interface ( IDL and DlgAutoProxy ) work fine.

Does the fact that I made this a multi-threaded application have anything to do with my problem and will the IMPLEMENT_OLECREATE2 macro fix this if I change the TRUE to FALSE.
Watch Question

>>>> The server has a GUI and the GUI was moved to the 2nd CWinThread.

The main part of a MFC GUI was the so-called message loop (or message bump). In a MFC application the message loop was in the CWinApp::Run. CWinApp is the base class of CYourApp (if you created your GUI with the MFC framework), and CWinApp was derived from CWinThread.

I would assume you didn't completely move the GUI to the 2nd thread, hence the main message loop still was active and is responsible for the behavior you were experiencing. Generally, I don't think it is a good idea to move the MFC GUI to a second thread. A newly generated CWinThread derived class object only has a 'pseudo window' associated with, which is for messaging purposes only. You would need to move the whole MFC framework to the second thread and I can't see any advantage of doing so. Better let the GUI on the main thread and put all non-GUI parts into the 2nd thread. Note, driving 2 GUI's with two threads isn't a good idea either cause you would need to have a completely separated messaging system between the GUI's. It is much easier for example to have two modeless dialogs within the main thread.

Regards, Alex

Author of the Year 2009
I concur.
When multithrreading with MFC, its best (least complicated, least error prone) to do all of the U/I in the main thread, and spin off worker threads that do *none* of the U/I.  Isolate tasks that do not require user interaction, and put those into worker threads.

A common need is to display a status gauge indicating how much of a worker thread's task is complete.  The best way to do that is to have he worker thread simply maintain a variable indicating what percentage is done.  Then use a timer in the GUI to monitor that value and display the progress.


My thanks for both comments. It turns out that IMPLEMENT_OLECREATE2 "FALSE" will turn the server into a singleton application ( provided all other things are done properly - such as RegisterActiveObject and RevokeActiveObject used with GetActiveObject COM marshalling.
The actual problem is far removed from the perceived problem. Further debugging revealed that the usual DoDataExchange mechanism used with UpdateData fails totally, in that it loses all subclassed control addresses. Since only GUI elements are involved it explains why other methods that have nothing to do with the GUI do actually work.
Your advice has convinced me to take the easy way out. Move the GUI back into the CWinApp thread and use a worker thread and syncronization events to block the premature return to the user.


The question turned out to be off the mark. My thanks again. You have convinced me to go back to basics.