Problems with Open-Source Downloads read and

QDialog stops updating when launched from QMainWindow running from an Eclipse RCP app Java plugin on Windows 10 64-bit?

  • Ok, so I have a Qt 4.8.7 gui running in an Eclipse RCP app from a Java plugin. I have a QMainWindow parented by a QWinWidget (from qtwinmigrate) which is parented by a org.eclipse.swt.widgets.Composite and displayed in an org.eclipse.ui.part.EditorPart. I use the IStartup interface to allocate the QApplication object on Eclipse app startup via a JNI call in the Java gui thread, i.e. Display.getDefault().syncExec(new Runnable() {... Interestingly, calling exec() on the QApplication object is not required as the Qt event queue appears to be happily processing along after QApplication is allocated.

    Amazingly, this works without issue on Windows 7/8 64-bit. However, when I take the exact same build and run it on Windows 10 64-bit, any QDialog launched from the QMainWindow stops updating, i.e. the QListWidget (in the QDialog) stops painting the mouse over item highlighting, it stops painting the selected item, tool button tooltips and mouse overs stop painting, checkboxes don't draw the check, etc. However, when I click outside of the app entirely, like on the taskbar, all the painting happens. But when I click back in the dialog, I get one click, or hover, and it's back to not painting again. I installed a global event filter and mouse clicks, hovers, and tracking, and tool tip timers are all occurring, it's just not getting to the widgets to trigger a re-paint. I believe the UpdateRequest event is getting gummed up somewhere, but I am unable to figure out how or where because when I hit the breakpoint where I think things are going wrong, the focus change to Visual Studio is un-gumming it up. I have so many print statements in QApplication, QCoreApplication, and QEventDispatcherWin32 it ain't funny, but I still can't make heads or tails out of what's going on.

    Weird, huh? Any ideas on what changed between Windows 7/8 and 10?

    Let me reiterate. This works flawlessly on Windows 7/8 64-bit. The issue is under Windows 10 64-bit. Unfortunately, I'm unable to share code. Also, I realize what I've done here is a bit insane, but it is what it is because legacy. I also can't "try" Qt5 because also legacy, i.e. Qt3 support. It's kinda ugly.

    Anyways, any help or insights would be greatly appreciated.


    Update 1:

    I managed to get a Visual Studio remote debugging session going which allowed the app the keep focus when I hit my conditional breakpoint of "event->t == QEvent::UpdateRequest" at qcoreapplication.cpp(1405): QCoreApplication::postEvent(). From there, the WIN32 API method PostMessage(d->internalHwnd, WM_QT_SENDPOSTEDEVENTS, 0, 0) is called. From there, I was then able to figure out that execution gets stuck in the "while" loop in qeventdispatcher_win.cpp(721): QEventDispatcherWin32::processEvents(). I think it gets stuck because of the "continue" at line 801, i.e.

    if (d->internalHwnd == msg.hwnd && msg.message == WM_QT_SENDPOSTEDEVENTS) {
        if (seenWM_QT_SENDPOSTEDEVENTS) {
            // when calling processEvents() "manually", we only want to send posted
            // events once
            needWM_QT_SENDPOSTEDEVENTS = true;
        seenWM_QT_SENDPOSTEDEVENTS = true;

    I don't know why this is happening. I don't know why the behaviour is different in a QDialog vs a QMainWindow. All I can say is that I commented out that "continue" and the issue goes away. Can anyone even begin to explain this to me?

    Update 2:

    The difference between Win7 and Win10 is that on Win7, at qeventdispatcher_win.cpp(784),

    waitRet = MsgWaitForMultipleObjectsEx(nCount, pHandles, 0, QS_ALLINPUT, MWMO_ALERTABLE);

    times out, the loop is broken, and processEvents can finish. On Win10, MsgWaitForMultipleObjectsEx() never times out. There are messages constantly coming in, most of them are WM_QT_SENDPOSTEDEVENTS.

    Can anyone explain this please?

Log in to reply