1
votes

I have an application which calls into plugin DLLs. Some of those calls are done from a worker thread (i.e. not the UI thread), and just might popup a dialog with MessageBox. According to this (http://www.codeproject.com/Articles/121226/MessageBoxes-and-worker-threads) the effective UI thread is switched to the thread calling MessageBox. This "crashes" the application since the message pump stops receiving messages. Any way to switch back the UI thread to the correct one ? Any work-around ?

1
That's complete nonsense. - Hans Passant
Agreed. MessageBox() is thread-safe and works perfectly fine in worker threads. Other threads do not stop receiving messages when MessageBox() is called in a worker thread. Something else is going on. - Remy Lebeau
Really Hans, Remy ? Have you tried ? Do you have reference to documentation backing that up ? Anyway, if something else is going on, I'd really like to know what it might be. True enough, I use the JUCE framework for the application, but the layer above Win messaging is extremely thin, so with the reference above I'm still wondering... - Robert
The article you linked to is complete bogus. Everything marked as Fact isn't. A Windows application doesn't have a single dedicated GUI thread. Any thread can be propagated to a GUI thread, and multiple GUI threads can run in parallel. A GUI thread is simply a thread that has a message queue. When your worker thread displays a message box it has been propagated to a GUI thread, and you must run a message loop on that thread to dispatch messages. - IInspectable
Yes, and I have now tried a raw MessageBox popup, and it doesn't mess up the system. Although this article too says that using GUI in a worker thread is a no-no: codeproject.com/Articles/552/Using-Worker-Threads - Robert

1 Answers

0
votes

The culprit was AttachThreadInput, see this message.