10

Qt v4.8.0, VC2010 compiler

I have a QMainWindow based class and I'm trying to send it signals involving QUuid

However, every time I run it I get the errors:

Object::connect: No such slot MainWindow::on_comp_connected(QUuid) in ..\..\src\mainwindow.cpp:143
Object::connect:  (receiver name: 'MainWindow')

It's driving me potty as the slot definitely does exist (it's in the moc_)

class MainWindow : public QMainWindow
{
Q_OBJECT

// SNIP private typedefs

public:
    MainWindow(QWidget *parent = 0, Qt::WFlags flags = 0);
    ~MainWindow();
// SNIP public methods

signals:
   void testSendQuuid(const QUuid &qcid);

public slots:
   void on_comp_connected(const QUuid &qcid);

private:
// SNIP private parts

QOpenAcnController *acnInt;  // This is where the signal comes from

};

At the end of the MainWindow constructor (the line 143 mentioned) I have:

connect(acnInt, SIGNAL(callback_comp_connected(QUuid)),
        this, SLOT(on_comp_connected(QUuid)));

Given that the slot is definitely there in the moc_mainwindow.cpp (I checked, it's slot #1), what on earth could be stopping the connection happening?

If I try to connect the testSendQuuid(QUuid) signal to the slot, I get no such signal and no such slot as well.

I cannot for the life of me figure out why Qt is denying the existence of a slot that is most definitely there!

AAEM
  • 1,837
  • 2
  • 18
  • 26
Richard1403832
  • 673
  • 1
  • 9
  • 16

4 Answers4

11

I solved problem by adding Q_OBJECT macro in mainwindow class.

FONQRI
  • 368
  • 4
  • 13
8

Check whether whether that moc_mainwindow.cpp is in your Build Path. Or you are using some other moc_window.cpp file. Because, for ex: In QtCreator, it build the source to a new build directory. And also it uses old moc_cpp file(s) if you try to open the source in a different location.

What I am trying to say is the moc file which you checked may contain those slot definition, but compiler might be using some other moc file which was created earlier.

ScarCode
  • 3,074
  • 3
  • 19
  • 32
  • That was it - somehow an extra moc_*.cpp had ended up in the build output folder instead of the moc folder, and clean didn't delete it. – Richard1403832 May 21 '12 at 11:41
  • This clean step normally doesn't clean those moc files, for ex: when you export a project from another system which was build there, and execute clean step in your system, like that. – ScarCode May 21 '12 at 11:46
  • so if I have a moc_maindwindow.cpp file in my vuild directory thats the cause for this error? Or if ti isn't there? you aren't that clear. I have the same problem and I have a moc_mainwindow.cpp in my build folder. so should I delete it or should I be fine as it IS there? – dhein Jul 22 '15 at 11:05
  • Clean the project and then build it. check the path in which the moc files are generated and check there whether its getting deleted by clean operation. Otherwise delete all moc files and build. If you still cant solve it copy the project(only source files and not build binaries) to a different path and try building the source. Still the problematic, review the modification you have done. Also check whether visual studio has write permission on the bin out directories. – ScarCode Jul 23 '15 at 12:00
1

I solved the problem like this

private slots:
    void on_comp_connected(const QUuid &qcid);

then in constructor

connect(tabWidget, SIGNAL(currentChanged(int)), this, SLOT(on_comp_connected(QUuid)));
James
  • 111
  • 9
0

You need

connect(acnInt, SIGNAL(callback_comp_connected(QUuid)),         this, SLOT(on_comp_connected(const QUuid&)));

Pass by value shouldn't match pass a const reference.

But I tried it and it does. I created a minimal project with QtCreator 2.4.1 using Qt 4.7.4 on Windows. I added a single label to the main window and modified MainWindow.cpp as follows

#include "mainwindow.h"
#include "ui_mainwindow.h"

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
    connect(
      this, SIGNAL(testSendQuuid(QUuid)),
      this, SLOT(on_comp_connected(QUuid))
    );
    QUuid x = QUuid::createUuid();
    emit testSendQuuid(x);
}

MainWindow::~MainWindow()
{
    delete ui;
}

void MainWindow::on_comp_connected(const QUuid &qcid)
{
    ui->label->setText(qcid.toString());
}

And I get a uuid on my main window.

I also tried with the two QUuid arguments in the connect changed to const QUuid& and that worked too.

So your problem must be build related.

Julian
  • 1,522
  • 11
  • 26
  • Hmm, will try that. Certainly sounds plausible. Odd that the Qt Creator would autocomplete incorrectly though. – Richard1403832 May 18 '12 at 17:29
  • 1
    This isn't it. They 'normalize' the signature for the connection, turning const references into values since the two are compatible. – cgmb May 18 '12 at 17:38
  • I'm sure you can connect them, but are you sure the moc will match them? – Julian May 18 '12 at 18:01
  • What sort of matching do you expect the moc to do? It doesn't match signals to slots. It just builds the meta-object information needed to enumerate methods. The connections are built at runtime and the OP is using `QObject::connect`, which is robust to those minor signature differences. – cgmb May 18 '12 at 22:53
  • 1
    const T& and T are equivalent when it comes to signals and slots, and there is no need to type const T&, ever (and it's even slower at runtime due to the normalization). – Frank Osterfeld May 19 '12 at 11:44
  • They certainly seem equivalent. I'm intrigued there is a run time difference, but I guess at the sending end there is probably a need for copy semantics, which throws away the normal advantage of a ref being a 'safer' pointer. – Julian May 19 '12 at 11:53