C++ Qt Signal and Slot Not Firing

C++ Qt signal and slot not firing

Add Q_OBJECT to your class, like this:

class MainWidget : public QWidget
{
    Q_OBJECT

You also have to run moc to generate some helper code. qmake does that automatically for your, but if you compile this yourself, you need to run moc.

Connecting signal and slot not working Qt

It's just what I was thinking, you have created a called mButtons, and that you have connected to your signal, but that button has no parent is not visualized since it is deleted when you finish executing the constructor, that does not mean that the pointers that you save in QVector are deleted from memory but they subsist and emit the signals, but these are not connected to any slot.

What you have to do is create a button that only emits the signal:

#ifndef MYBUTTON_H
#define MYBUTTON_H

#include <QMouseEvent>
#include <QPushButton>
#include <QDebug>

class MyButton : public QPushButton
{
 Q_OBJECT

public:
    MyButton(QWidget *parent = Q_NULLPTR):QPushButton(parent){

    }

protected:
    void mousePressEvent(QMouseEvent *e) {
        if(e->button()==Qt::RightButton) {
            emit btnRightClicked();
            qDebug() << "Emitted";
        }
    }

signals:
    void btnRightClicked();
};
#endif // MYBUTTON_H

Then you create a container of buttons, and in the loop you create the buttons and connect it:

*.h

private slots:
    void onRightClicked();

private:
    QVector<MyButton *> mButtons;
};

*.cpp

QWidget *mWidget = new QWidget(this);
QGridLayout *gLayout = new QGridLayout(mWidget);
for(int i = 0; i < 5; i++) {
    MyButton *btn = new MyButton(mWidget);
    gLayout->addWidget(btn, 0, i);
    connect(btn, &MyButton::btnRightClicked, this, &MainWindow::onRightClicked);
    mButtons << btn;
}

mWidget->setLayout(gLayout);
setCentralWidget(mWidget);

You can download the example in the following link

Signals and slots not working in qt

You're only connecting the dialog instance you created locally in the Bestiary's constructor, which goes out of scope as the constructor finishes.

connect is connecting instances, not classes. That means you need to connect each created dialog:

void Beastiary::on_pushButton_clicked() {
    Dialog* ad = new Dialog(this);
    connect(ad, SIGNAL(gorefresh()), this, SLOT(refresh()));
    ad->show();
}

While at it, you should seriously consider using the type-safe connect syntax that came with Qt 5:

void Beastiary::on_pushButton_clicked() {
    Dialog* ad = new Dialog(this);
    connect(ad, &Dialog::gorefresh, this, &Bestiary::refresh));
    ad->show();
}

QT signal slot is not working

You are not starting a main event loop.

your main function should look something like this:

QApplication app(argc, argv);
A a;
a.callA();
return app.exec();

Qt queued connections can't work if there is no event loop running in the receiving thread.

When the receiver object lives in a thread other than the thread where the signal is emitted, Qt::AutoConnection uses a Qt::QueuedConnection, see docs.

A Qt::QueuedConnection works by posting an event to the event loop of the target thread (the thread where the receiver QObject lives). When that event is processed (by the event loop) the call to the slot is invoked in the target thread.

In your case, the main thread is always stuck in:

while(1)
    sleep(1);

So, it will never be able to execute anything else.

QT signal and slot connection not working

I think the problem may be in the fact that you have g->gameLoop(); BEFORE the connect. If your someFunction is called from the gameLoop, then the connect is performed only after the game has finished and after the execution returns from the gameLoop(). But of course it's just guessing. I wouldn't expect to see 'gameLoop' called from the Window's constructor so.. it looks odd as well. Other than that, it looks fine, so if my guess is not correct, then probably the problem lies elsewhere in the code we don't see.

My signal / slot connection does not work

There are some rules that make life with signals and slots easier and cover the most common reason for defective connections. If I forgot something please tell me.

1) Check the debug console output:

When execution errors occur, the debug output can show you the reason.

2) Use the full signature of signal and slot:

Instead of

connect(that, SIGNAL(mySignal), this, SLOT(mySlot));

write

connect(that, SIGNAL(mySignal(int)), this, SLOT(mySlot(int)));

and check your spelling and capitalization.

3) Use existing overloads:

Carefully check if you are using the desired overloads of signal and slot and if the overloads you used actually exist.

4) Your signal and slot must be compatible:

This especially means the parameters must be of the same type (references are tolerated) and have the same order.

Compile-time syntax also needs the same number of parameters. Old runtime syntax allows connecting signals to slots with less parameters.

5) Always check return value of connect method (programmers should never ignore return values):

Instead of

connect(that, SIGNAL(mySignal(int)), this, SLOT(mySlot(int)));

always use something like

bool success = connect(that, SIGNAL(mySignal(int)), this, SLOT(mySlot(int)));
Q_ASSERT(success);

Or if you like throw an exception or implement full error handling. You may also use a macro like that:

#ifndef QT_NO_DEBUG
#define CHECK_TRUE(instruction) Q_ASSERT(instruction)
#else
#define CHECK_TRUE(instruction) (instruction)
#endif 

CHECK_TRUE(connect(that, SIGNAL(mySignal(int)), this, SLOT(mySlot(int))));

6) You need an event loop for queued connections:

I.e. when ever you connect signals/slots of two objects owned by different threads (so called queued connections) you need to call exec(); in the slot's thread!

The event loop also needs to be actually served. Whenever the slot's thread is stuck in some kind of busy loop, queued connections are NOT executed!

7) You need register custom types for queued connections:

So when using custom types in queued connections you must register them for this purpose.

First declare the type using the following macro:

Q_DECLARE_METATYPE(MyType)

Then use one of the following calls:

qRegisterMetaType<MyTypedefType>("MyTypedefType"); // For typedef defined types
qRegisterMetaType<MyType>(); // For other types

8) Prefer new compile time syntax over old run-time checked syntax:

Instead of

connect(that, SIGNAL(mySignal(int)), this, SLOT(mySlot(int)));

use this syntax

connect(that, &ThatObject::mySignal, this, &ThisObject::mySlot));

which checks signal and slot during compile time and even does not need the destination being an actual slot.

If your signal is overloaded use the following syntax:

connect(that, static_cast<void (ThatObject::*)(int)> &ThatObject::mySignal), this, &ThisObject::mySlot); // <Qt5.7
connect(that, qOverload<int>::of(&ThatObject::mySignal), this, &ThisObject::mySlot); // >=Qt5.7 & C++11
connect(that, qOverload<int>(&ThatObject::mySignal), this, &ThisObject::mySlot); // >=Qt5.7 & C++14

Starting with Qt5.14, overloaded signals are deprecated. Disable deprecated Qt features to get rid of the above shenanigans.

Also do not mix const/non-const signals/slots for that syntax (normally signals and slots will be non-const).

9) Your classes need a Q_OBJECT macro:

In classes where you are using "signals" and "slots" specifications you need to add a Q_OBJECT macro like this:

class SomeClass
{
   Q_OBJECT

signals:
   void MySignal(int x);
};

class SomeMoreClass
{
   Q_OBJECT

public slots:
   void MySlot(int x);
};

This macro adds necessary meta information to the class.

10) Your objects must be alive:

As soon as either the sender object or the receiver object is destroyed, Qt automatically discards the connection.

If the signal isn't emitted: Does the sender object still exist?
If the slot isn't called: Does the receiver object still exist?

To check the lifetime of both objects use a debugger break point or some qDebug() output in the constructors/destructors.

11) It still does not work:

To do a very quick and dirty check of your connection emit the signal by your self using some dummy arguments and see if it is called:

connect(that, SIGNAL(mySignal(int)), this, SLOT(mySlot(int)));
emit that->mySignal(0); // Ugly, don't forget to remove it immediately

Finally of course it is possible that the signal simply is not emitted. If you followed the above rules, probably something is wrong in your program's logic. Read the documentation. Use the debugger. And if there is now other way, ask at stackoverflow.

---

Related Topics