>>Not typically. These are the responsibilities of a message-loop thread and there shouldn't be other threads interfering with these responsibilities.
Right, but GUI events typically signify:
-You want the program to do something -> access data that the main thread is using
-You want the program to display data -> access data that the main thread is modifying
If the window procedure has to display data that the main thread is using, i.e. tying up with a blocking operation, then we've still got a message clog as we wait for the main thread to finish up and release control; and if a buttonclick is supposed to trigger a lengthy operation, then we'll have a message clog again (especially if the button event also needs access to that data we're sitting on). Unless, I suppose you might just spawn another worker thread to handle the buttonclick?
The MDI example makes more sense to me though, since each window/thread acts as more or less an independent, self-contained application with little or no data sharing; and the main thread just acts as the glue and slavedriver, sticking them all together and telling them to open or close.
