2008 MFC and threads?

Question

I was reading this thread/post: http://stackoverflow.com/questions/262298/windows-c-ui-technology

and am also wondering about a non .NET UI framework. Specifically - prior to .NET having support for serial ports (I can't believe they left that out of the first release of .NET) I was forced to use MFC for an application. I had not been a GUI developer and quickly found myself pulling my hair out due to the horrendous lack of ability for MFC to play nice with other threads in my app - e.g. calling a UI control method to update data or do other things from another thread. Most of those challenges were dealt with, but the application code is so overly complex with messaging and the like just to handle the shortcomings of MFC.

So - my question: does the "New and improved" mfc have support for threads - i.e. if I call some mfc control for a gui object from another thread will it crash/puke like the old mfc, or can it play in the real world?

EDIT

To clarify - I understand the concern about munging with the GUI in separate threads, but what I was hoping for was that instead of the programmer creating custom messages and sending them from the worker threads - that the GUI framework would do all that work for me and I could just call the object methods from other threads. Perhaps that is too much to hope for - especially if threads are not part of the language spec yet.

Answer 1

This is not a limitation of MFC - it's the design of Windows. You can't start sending messages to arbitrary controls from random other threads. (Well, you can, sometimes, but you need to know what you're doing.) This is equally true in the .NET world - once a control is visible you need to use a delegate to update it, so that the updating action occurs on the correct thread.

More generally, I'd say that from experience, you're almost always better off only having one thread handling the GUI in an application, and making the remaining threads purely workers. Having multiple threads interact with the GUI leads to madness trying to keep track of what's going on.

EDIT

The short answer to the original question is, I'm afraid, "no": there's been no fundamental re-work of how threads, MFC and Windows interact. At this point, with MFC hardly being a priority at Microsoft, I don't expect this to change.

Answer 2

One thing you can do is to post a custom message to yourself, the windows message pump will take that message and process it on the main thread, so all your code will work ok. Obviously you need to set yourself up to work with your windows in an asynchronous fashion, but that's the whole design of Windows windowing.

You can use worker threads to help out, but keep your GUI work on the main thread.

You'll find most windowing toolkits are single threaded too (as there tends to be a single user using them :) ), the ones that aren't are more complex than they're worth.

Answer 3

The basic architecture of MFC hasn't really changed in the new version. If you weren't happy with the threading support previously then it's safe to say that you still won't be. I'd agree with what DavidK said - this is an inherent issue that all frameworks have to deal with. The main reason that MFC doesn't provide much help for multithreading is almost certainly because it was originally introduced in 1992 for 16-bit Windows. At this time Windows did not support multitasking, and was effectively single threaded.

Answer 4

use .NET gui and thread, main application code in MFC dll.

call it through c# delegate