Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QtWinMigrate not working with Qt5

QtWinMigrate not working with Qt5

Scheduled Pinned Locked Moved General and Desktop
2 Posts 2 Posters 2.0k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Al W
    wrote on last edited by
    #1

    I am having trouble upgrading a Qt GUI DLL to Qt5.3 from Qt4.8. We are using QtWinMigrate to load the DLL from a Win32 application. We are unable to change the Win32 app. The problem we are seeing is the same that is mentioned in this thread:

    http://qt-project.org/forums/viewthread/30038

    i.e. that all the GUI elements are completely unresponsive, e.g. buttons can't be clicked.

    The issue is taken up by the author of this thread in this bug report:
    https://bugreports.qt-project.org/browse/QTBUG-32962

    The bug was marked as closed because the author believed it was fixed. This is not the case as in another thread here:

    http://lists.qt-project.org/pipermail/development/2013-December/014592.html

    the author mentions he had a local work around in place when he stated that it was fixed.
    The issue seems to be that
    @
    void QWindowsGuiEventDispatcher::sendPostedEvents()
    {
    QCoreApplication::sendPostedEvents();
    QWindowSystemInterface::sendWindowSystemEvents(m_flags);
    }
    @

    is not called, but the base class
    @
    void QEventDispatcherWin32::sendPostedEvents()
    {
    Q_D(QEventDispatcherWin32);
    QCoreApplicationPrivate::sendPostedEvents(0, 0, d->threadData);
    }
    @

    which doesn't send windows events. It's called from qt_internal_proc in qeventdispatcher_win.cpp.
    The pointer to the dispatcher is a static cast from a GetWindowLongPtr, so as far as I can see it will always call the base class.

    It can sort of be made to work by hacking QtFilterProc in qmfcapp.cpp to add the line
    @
    QWindowSystemInterface::sendWindowSystemEvents(QEventLoop::AllEvents);
    @

    but it is slow and some bits. e.g. combo boxes, still do not work.

    So are there any ideas how to go about fixing this? Or are there any workarounds? The architecture of the controlling application means we can't start an event loop in another thread, though this could be a workaround in other cases.

    1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi and welcome to devnet,

      You have there a good and interesting analysis, however the forum might not be the best place for such a low-level question. You should rather try to write to the development mailing list to discuss the implementation used by the original author since he seemed to have successfully implemented what you are trying to do.

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0

      • Login

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • Users
      • Groups
      • Search
      • Get Qt Extensions
      • Unsolved