Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-65014

Signals are not emitted if QAxControl is put on D-Bus and no other slots connect to the signals



    • Type: Bug
    • Status: Open
    • Priority: P3: Somewhat important
    • Resolution: Unresolved
    • Affects Version/s: 5.6.3
    • Fix Version/s: None
    • Component/s: ActiveX Support, D-Bus
    • Labels:
    • Environment:
      Windows 10


      If QAxControl is used to load an ActiveX control, and this object is then put on the D-Bus with QDBusConnection::registerObject() then slots and signals are all visible via the D-Bus interface, and you can call the object's slots via the D-Bus as you would expect, but QAxControl never emits any of the signals defined by the underlying ActiveX control.

      If you then connect one of these signals to a regular slot, they are emitted, both on the normal slot, and via the D-Bus.




      auto ax = new QAxObject(this);
      if (!ax->setControl("someaxcontrol")) {
          delete ax;
          return false;
      // at this point, if someaxcontrol dispatches an event, ax will not emit a Qt signal
      // now, connect any other slot to the signal
      QObject::connect(ax, SIGNAL(somesignal()), this, SLOT(dummy()));
      // and now, if somecontrol dispatches the somesignal event, it will be
      // emitted as Qt signal, so dummy() will be called, and the corresponding
      // signal will be emitted on the D-Bus as well


      The problem seems to be a combination of factors:

      1. After QDBusConnection::registerObject tries to connect the object's signals, QObject::receivers() still returns 0. Apparently it does not count the receivers connected in this manner.
      2. In QAxEventSink::Invoke, signalHasReceivers is called, which again calls QObject::receivers(). As this returns 0, QAxEventSink decides that no on is listening for the signal, and skips emitting it.

      I'm unsure if the root cause is that QObject::receivers() doesn't count connections made through QDBusConnection::registerObject, or if QAxEventSink should be smarter about how it tests if anything is connected to the signal.

      If the object being registered on the D-Bus is a regular QObject with statically defined slots, it works correctly. The signals are then emitted through QMetaObject::activate, which uses different logic to determine if anyone is connected to the signal, which correctly count the QDBusConnection as being connected.


        No reviews matched the request. Check your Options in the drop-down menu of this sections header.



            jalf jalf
            0 Vote for this issue
            3 Start watching this issue



                Gerrit Reviews

                There are no open Gerrit changes