Signals emitted from derived class trigger multiple slots

[PhTe]

Hi,
i have a problem with some signals/slots.

I have a base class which contains a signal:

class ModalDialog : public QObject {
    Q_OBJECT

...

signals:
    void dialogClosed(bool success);
};

and two derived classes:

class WaitDeviceDialog : public ModalDialog {
    Q_OBJECT
...
    void close() {
        // Do some crazy stuff...
        emit dialogClosed();
    }
};

class ExportDialog : public ModalDialog {
    Q_OBJECT
...
    void close() {
        // Do some other stuff...
        emit dialogClosed();
    }
};

In my application i create instances of both derived classes and connect the signals:

...
this->exportDlg = new ExportDialog();
this->waitDlg = new WaitDeviceDialog();
...
connect(this->exportDlg, SIGNAL(dialogClosed(bool)), this, SLOT(onExportDialogClosed(bool)));
connect(this->waitDlg, SIGNAL(dialogClosed(bool)), this, SLOT(onWaitDialogClosed(bool)));
...

My problem now is, that always both slots are executed regardless of which dialog the signal emitted.

So if the ExportDialog was visible and closed it emitted the dialogClosed event and the corresponding onExportDialogClosed function is called. But also the onWaitDialogClosed function is called and i dont know why...

Does somebody has an idea?

Edit: It's Qt 5.4.1 on a Linux system.

[Taz742]

@PhTe
You could write (show) a onExportDialogClosed and onWaitDialogClosed functions?

[jsulm]

@PhTe said in Signals emitted from derived class trigger multiple slots:

emit dialogClosed();

You do not pass true/false to the signal! Your signal has a bool parameter. It should actually not even compile.

[VRonin]

Do you have any static/singleton stuff going on in the background?

[J.Hilk]

For some basic steps to debug this I would try:

• comment one connect out. That way youcan actually see if you have the correct connect statement or if somewhere else in the code the problem is happening
• change to the new QT5 Signal/Slot Syntax

@jsulm that is one of the major reasons why I prefere the new over the old Syntax. This would indeed not compile with the new syntax but it should be valid in the old one, but should fail to execute the slot.

[jsulm]

@J.Hilk I don't mean the connect. This one should not compile if there is no such signal:

emit dialogClosed();

[J.Hilk]

@jsulm oh, right. Might be a typo or the the signal is qactully defined with a default value:

signals:
    void dialogClosed(bool success=true);