QObject::connect: No such slot error

tomy

Hi,

In my app, a spreadsheet program, files can be closed using either the close or exit button or the Windows built-in red X button.
I have declared a static QVector<QString> vf to push the names of the opened files and remove their names once they are closed. I'm now working on the close button.

This is closeAction:

closeAction = new QAction(tr("&Close"), this);
closeAction->setShortcut(QKeySequence::Close);
closeAction->setStatusTip(tr("Close this window"));
connect(closeAction, SIGNAL(triggered(bool)), this, SLOT(close()));   
connect(closeAction, SIGNAL(triggered(bool)), this, SLOT(remove_File(curefile)));

I've declared the remove_File slot and it's its implementation:

bool MainWindow::remove_File(QString &fileName)
 {
     for(int i=0; i<vf.size(); ++i)
         if(fileName == vf[i]) {
             vf.removeAt(i);
             return true;
         }
    return false;
 }

Now the app runs successfully but I get this message in Application Output window regarding connect:

QObject::connect: No such slot MainWindow::remove_File(curefile) in ..\MainWindow\mainwindow.cpp:227

The message's statement is odd for me because I've declared and also implemented the slot. What can be the problem please?

mpergand

The slot must be SLOT(remove_File(bool)) or SLOT(remove_File())

If you need to pass an additional parameter, have a look at QSignalMapper

There's a complete example here

tomy

@mpergand
I tested both cases. The same result. It's expected for me because bool MainWindow::remove_File(QString &fileName) needs a QString to be correctly invoked.

curefile is a local variable and not suitable to be used there. And I don't know how to extract the name the file being closed to send for the remove_File slot.

mpergand

show us the signals and slots declarations in the .h file

SGaist

Hi,

If you had taken the time to search a bit for that error, you would have found that there's already a lot of similar question on that forum with the same answer: you don't pass parameters at connection time.

If you want to remove and close, then use a dedicated slot for that. That way you will also ensure that the remove file happens before the close.

tomy

@SGaist

If you want to remove and close, then use a dedicated slot for that. That way you will also ensure that the remove file happens before the close.

Yes, good point. So I can dedicate a slot where I can first remove the file name from the vector and then call the built in close function.
Still thinking of how to find the name of the file!

SGaist

Isn't that the job of your curefile variable ?

tomy

Here is the fisrt version of the program.

A typo (as usual!).

SGaist

What do you mean by "A typo" ?

tomy

@SGaist

What do you mean by "A typo" ?

I'd used curefile rather than curFile!

I tested the program and it's fine with both close and exit now. Now there remain two problems:
How to handle the Windows red X button?
And the built-in closeAllWindows() slot (connected to the exit button), closes all windows when clicked, but when I create an installer exactly using the program's .exe file, that exit button only closes its file not all files!

SGaist

Then you can re-implemnet the closeEvent function to do the removal before proceeding further.

tomy

@SGaist
Done! Thank you, handy help about closeEvent.

When I create an installer and install the app on my Windows machine, the open button works as expected and doesn't open the opened files again but using double click I can open the same files as many times as I like.

Here is main.cpp:

#include <QApplication>
#include <QSplashScreen>
#include "mainwindow.h"

int main(int argc, char* argv[])
{
   QApplication app(argc, argv);

   QSplashScreen* splash = new QSplashScreen;
   splash->setPixmap(QPixmap(":/images/splash.jpg"));
   splash->show();

   Qt::Alignment topRight = Qt::AlignRight | Qt::AlignTop;
   splash->showMessage(QObject::tr("Setting up the main window..."),
   topRight, Qt::white);

    MainWindow* mainWin = new MainWindow;

    if(argc > 1)
        mainWin->loadFile(argv[1]);

    mainWin->show();
    splash->finish(mainWin);
    delete splash;

    return app.exec();
}

It calls loadFile:

bool MainWindow::loadFile(const QString &fileName)
{
    if(already_Opened(fileName))
        return false;
    else vf.push_back(fileName);

    if (!spreadsheet->readFile(fileName)) {
        statusBar()->showMessage(tr("Loading canceled"), 3000);
          return false;
    }

    setCurrentFile(fileName);
    statusBar()->showMessage(tr("File loaded"), 3000);
    return true;
}

Here is already_Opened also:

bool MainWindow::already_Opened(const QString &fileName)
{

   for(int i=0; i<vf.size(); ++i)
       if(fileName == vf[i])
           return true;
   return false;
}

vf is a vector of QString. What can be the problem in your point of view?

SGaist

Likely that you are opening your application several times.

Also, you're not destroying your MainWindow object properly.

I don't see why you need to use a static variable for your vector.

Also, you should take a look at the documentation of the class you are using, you are reimplementing by hand a method that already exists in QVector. See contains.

tomy

@SGaist

Also, you should take a look at the documentation of the class you are using, you are reimplementing by hand a method that already exists in QVector. See contains.

Thanks, good method. I used it.

Likely that you are opening your application several times.

Also, you're not destroying your MainWindow object properly.

I don't see why you need to use a static variable for your vector.

I think the issue belongs to running the program by double clicking, so that a double click runs the program and opens a file and the next double click runs the program once again and opens that file again and so on.
I declared the vector static so that there is only one vector for any execution.

Incidentally, the program uses the statements:

MainWindow* mainWin = new MainWindow;  
mainWin->show();

two times in main.cpp and newFile():

#include <QApplication>
#include <QSplashScreen>
#include "mainwindow.h"

int main(int argc, char* argv[])
{
   QApplication app(argc, argv);

   QSplashScreen* splash = new QSplashScreen;
   splash->setPixmap(QPixmap(":/images/splash.jpg"));
   splash->show();

   Qt::Alignment topRight = Qt::AlignRight | Qt::AlignTop;
   splash->showMessage(QObject::tr("Setting up the main window..."),
   topRight, Qt::white);

    MainWindow* mainWin = new MainWindow;

    if(argc > 1)
        mainWin->loadFile(argv[1]);

    mainWin->show();
    splash->finish(mainWin);
    delete splash;

    return app.exec();
}

void MainWindow::newFile()
{
    MainWindow* mainWin = new MainWindow;
    mainWin->show();
}

Also, for destroying the objects when closed, I use, setAttribute(Qt::WA_DeleteOnClose); in the Mainwindow's constructor.

SGaist

Then if you don't want that to happen, then you have to ensure that there's only one instance of your application running using for example the QtSingleApplication class.

Why use a new MainWindow for every document ? The editor itself should rather be a dedicated widget.

tomy

@SGaist

Then if you don't want that to happen, then you have to ensure that there's only one instance of your application running using for example the QtSingleApplication class.

Does it mean that the user will have only one file opened at the same time? The user may need to open various files and compare, say, the data of two of them at the same time.

Why use a new MainWindow for every document ?

Do you mean new MainWindow in newFile() slot or main?
Please take a look at the explanations of the book about these:
https://www.imageupload.co.uk/images/2017/09/12/131a64.png
https://www.imageupload.co.uk/images/2017/09/12/25f435.png
https://www.imageupload.co.uk/images/2017/09/12/3.png
https://www.imageupload.co.uk/images/2017/09/12/4.png

The book has meant an SDI, and for that it has suggested a foreach loop. I didn't understand that loop well and couldn't use it so went for employing a vector.

I'm still rather astonished by this behaviour:
The double click sends the name of the file to the loadFile slot so if it's previously opened, the first if statement closes the function and the program execution doesn't reach the function spreadsheet->readFile(fileName) and the file shouldn't open once again, but in effect, it opens again. Isn't it strange?

The editor itself should rather be a dedicated widget.

Editor?

(Sorry For the Delay)

BjornW

@tomy said in QObject::connect: No such slot error:

connect(closeAction, SIGNAL(triggered(bool)), this, SLOT(close()));
connect(closeAction, SIGNAL(triggered(bool)), this, SLOT(remove_File(curefile)));

As always in threads related to signals/slots, I must jump in to advocate the Qt5 syntax:

connect(closeAction, &QAction::triggered, this, &MainWindow::close);

because compile time connection checks are awesome :-)

SGaist

No, I mean having one instance of your application handling more than one file.

What book is that ?

No it's not strange, you are expecting your static variable to be the same across all instances of your application, that's wrong.

The editor: the widget used to edit your document.

6thC

@BjornW I'm with you - you can also hit F2 in the IDE and jump straight to a signal definition or slot implementation... so much win with QObject member connections.

tomy

@SGaist

No, I mean having one instance of your application handling more than one file.

It's likely the best choice. If I'm right I think it's related to MDI (Multiple Document Interface) which is what the book pointed to alongside that foreach loop, that I didn't understand well and not sure where, in what functions in the project, to write that loop.

What book is that ?

C++-GUI-Programming-with-Qt-4-2nd Edition

No it's not strange, you are expecting your static variable to be the same across all instances of your application, that's wrong.

The static variable is the same between instances of the application if we've created new instances using the menus and buttons. But each time we open new files using double clicking the event is different and it's as though we are executing the app for the first time. Disagree?