Signals/slots between classes

[been_1990]

I'm stuck at this.
I want to connect a slot, dialogAccepted(); , to a QDialogButtonBox "buttonBox" ,accepted() signal. My slot is in the class Widget and the signal comes from class Dialog(which is a public QDialog).
widget.cpp:


#ifndef WIDGET_H
#define WIDGET_H

#include <QtGui/QWidget>
#include "dialog.h"

namespace Ui
{
class Widget;
}

class Widget : public QWidget
{
Q_OBJECT

public:
Widget(QWidget *parent = 0);
~Widget();


private:
Ui::Widget *ui;
Dialog dialog;



private slots:
void dialogAccepted();
};

#endif // WIDGET_H

[vieraci]

Connect your signal before you show your dialog:

connect(dialog1, SIGNAL(whatever), this, SLOT(yourSlot));
dialog1->show();

[been_1990]

Well I get the following error:

F:/Documents/QT Projects/ANClock/widget.cpp:21: error: no matching function for call to `Widget::connect(Dialog&, const char*, Widget* const, const char*)'
This is the connect line:

connect(dialog, SIGNAL(accepted()),
this, SLOT(tempUsage()));

[squidge]

try

&dialog

[Tanuki-no Torigava]

Actually it looks like you put variable names in connect while you should connect only prototypes. Something like:



class myCustomWidget1: public QWidget
{
Q_OBJECT

public:

myCustomWidget1(QObject * parent = 0);
~myCustomWidget1();

signal:

drawMyPicture(int x, int y, const QPicture& pict);

};

class myCustomWidget2: public QWidget
{
Q_OBJECT

public:

myCustomWidget2(QObject * parent = 0);
~myCustomWidget2();

public slots:

void drawSomething(int x, int y, const QPicture& pict);

};

// Somewhere in your code
...
myCustomWidget1* widget1 = new myCustomWidget1(this);
myCustomWidget2* widget2 = new myCustomWidget2(this);

connect(widget1, SIGNAL(drawMyPicture(int, int, const QPicture&)),
widget2, SLOT(drawSomething(int, int, const QPicture&)));

Hope that helps.

[Tanuki-no Torigava]

PS.

connect(classOne, SIGNAL(classOneSignal(int x)), classTwo, SLOT(classTwoSlot(int x)));

will not produce any error but will not work while this one


connect(classOne, SIGNAL(classOneSignal(int)), classTwo, SLOT(classTwoSlot(int)));

works fine.

[Tanuki-no Torigava]

And just notice that you close the namespace Ui. So your declaration is incorrect. It should be
class Ui::Widget: public QWidget;
Also it is a bit strange declaration. Is it designer-made class?

[squidge]

PS.

connect(classOne, SIGNAL(classOneSignal(int x)), classTwo, SLOT(classTwoSlot(int x)));will not produce any error but will not work while this one
Actually, that WOULD produce an error, but at runtime when connect() is called, rather than compile time. You'll get an error stating that there's no such signal.

[been_1990]

try

&dialog

That's exactly what I did! I don't know why that works??:confused:

[been_1990]

And just notice that you close the namespace Ui. So your declaration is incorrect. It should be
class Ui::Widget: public QWidget;
Also it is a bit strange declaration. Is it designer-made class?

That's code generated from QtCreator.

[Tanuki-no Torigava]

Actually, that WOULD produce an error, but at runtime when connect() is called, rather than compile time. You'll get an error stating that there's no such signal.

I mean compile time error. Actually I do prefer to see compile time error instead of looking through the console. So you are half right. Run time error != build time error.

About dialog. Looks like you draw in designer, right? if so you need multiple inheritance where the first class is exactly the base class of your widget (QDialog, QScrollArea, etc) and second is your Ui based class.



// Login details dialog
class LoginDetails : public QDialog, public Ui::SyncDialog
{
Q_OBJECT

public:

LoginDetails(QWidget * parent = 0, Qt::WindowFlags f = 0);
~LoginDetails();
}

// And in the constructor of this class very urgent to keep the initialization sequence and don't forget to initialize Ui as well

LoginDetails::LoginDetails(
QWidget* parent,
Qt::WindowFlags flags)
: QDialog(parent, flags)
{
setupUi(this); // should go first!!!

// Your init

}


Hope that helps

[squidge]

I mean compile time error. Actually I do prefer to see compile time error instead of looking through the console. So you are half right. Run time error != build time error.
I thought I clearly stated that in my post:


Actually, that WOULD produce an error, but at runtime when connect() is called, rather than compile time. You'll get an error stating that there's no such signal.

It was a "Just for your information". I know it's not a compile time error, but you might not have known about it and thought it was useful. Considering connect() takes a char *, it's impossible for it to know at compile time that a signal doesn't exist. You can put whatever you like for the signal and slot and it'll be happy at compile time.

[squidge]

That's exactly what I did! I don't know why that works??:confused:It works because Dialog is created on the stack rather than the heap. It would be "Dialog *" if it was created on the heap, and then you'd need to use "dialog = new Dialog()" somewhere too. You could then also use connect(dialog, instead of connect(&dialog,

[faldzip]

Well I get the following error:

F:/Documents/QT Projects/ANClock/widget.cpp:21: error: no matching function for call to `Widget::connect(Dialog&, const char*, Widget* const, const char*)'
This is the connect line:

connect(dialog, SIGNAL(accepted()),
this, SLOT(tempUsage()));
This error says that there is no such 'connect' method? why? Because every connect needs pointers to an objects, not references or anything else. And as you see in your compile error:


Widget::connect(Dialog&, ...
the compiler is right in this case (as always) because it says you want to pass a reference to your dialog, not a pointer, and there is no suitable method.

So because you have in your header file:


Dialog dialog;

You have to use C/C++ '&' operator to get the pointer (address):


connect(&dialog,...

[been_1990]

I mean compile time error. Actually I do prefer to see compile time error instead of looking through the console. So you are half right. Run time error != build time error.

About dialog. Looks like you draw in designer, right? if so you need multiple inheritance where the first class is exactly the base class of your widget (QDialog, QScrollArea, etc) and second is your Ui based class.



// Login details dialog
class LoginDetails : public QDialog, public Ui::SyncDialog
{
Q_OBJECT

public:

LoginDetails(QWidget * parent = 0, Qt::WindowFlags f = 0);
~LoginDetails();
}

// And in the constructor of this class very urgent to keep the initialization sequence and don't forget to initialize Ui as well

LoginDetails::LoginDetails(
QWidget* parent,
Qt::WindowFlags flags)
: QDialog(parent, flags)
{
setupUi(this); // should go first!!!

// Your init

}


Hope that helps

You lost me here...:confused: Let me see if I understood right, I should use Multiple Inheritance instead of Single Inheritance? The code generated by QtCreator seems to be single inheritance, I never changed that, but is that necessary?
Yes I use the designer to create the forms..

[squidge]

Multiple Inheritance is generally a bad idea. You should use single inheritance unless you have a good reason. This way all your ui objects are behind the 'ui' object rather than exposed and polluting the same class as your implementation. Multiple inheritance also makes it more messy if another class includes your classes header file.

[been_1990]

It works because Dialog is created on the stack rather than the heap. It would be "Dialog *" if it was created on the heap, and then you'd need to use "dialog = new Dialog()" somewhere too. You could then also use connect(dialog, instead of connect(&dialog,

Heap? Stack?:confused::D

[squidge]

http://en.wikipedia.org/wiki/Stack-based_memory_allocation
http://en.wikipedia.org/wiki/Dynamic_memory_allocation

[been_1990]

Multiple Inheritance is generally a bad idea. You should use single inheritance unless you have a good reason. This way all your ui objects are behind the 'ui' object rather than exposed and polluting the same class as your implementation. Multiple inheritance also makes it more messy if another class includes your classes header file.

I read at QT archives that QT Creator uses single inheritance because that compiles much quicker and etc, etc ...
But there's this QT beginners tutorial that says multiple inheritance is the preferred way to write Qt applications.
Whatever.... So single inheritance is better?

[squidge]

Use whichever you prefer. I prefer single inheritance as it keep the ui private, but some prefer multiple so they can access the ui directly.