QtWinMigrate and QThread event loop

[dslee168]

I've recently discovered that if an application creates a new background QThread and calls QThread::start() to start the thread's event loop, that thread will sometimes process QMfcApp::winEventFilter, which in turn will cause MFC events to be processed in the background thread. However, this will cause some problems because the MFC events are only meant to be processed in the application's main thread.

Can anyone confirm if it will be ok to do a thread check inside QMfcApp::winEventFilter and only allow it to proceed if the current thread is the main thread? I'm not familiar with the lineage of this class, but the way it's written, I think there was an assumption that it would only get called from the main thread.

Thanks,

Doug

[Asido]

I would like to know a proper solution to this as well. In my case calling QNetworkAccessManager::get() puts main thread into QWaitCondition::wait() mode and QCoreApplication::winEventFilter() starts to get called from a worker QThread until QNAP::get() finishes it's task. That immediately crashes the application as MFC per-thread objects become inaccessible.
Bellow is my temporary solution, although it kinda defeats the whole point of multithreading as it becomes the same as doing network request on the main thread. Anyone is aware of a better alternative?

bool QMfcApp::winEventFilter(MSG *msg, long *result)
{
    if (QThread::currentThread() != QApplication::instance()->thread())
        return false;
 
    ...
}

bool QMfcApp::winEventFilter(MSG *msg, long *result)
{
    if (QThread::currentThread() != QApplication::instance()->thread())
        return false;

    ...
}

To copy to clipboard, switch view to plain text mode