connect slot signlas with class references?

[dennis]

Hi,

How do I pass the signals reference to the slot function? Take this snippet as an example:

connect(button, SIGNAL( mySignal(QString)  ), this, SLOT( mySlot(QString) ));
 
void MainWindow::mySlot(const QString &title)
{
    // how can I get the button reference in here?
}

connect(button, SIGNAL( mySignal(QString)  ), this, SLOT( mySlot(QString) ));

void MainWindow::mySlot(const QString &title)
{
    // how can I get the button reference in here?
}

To copy to clipboard, switch view to plain text mode 

I tried to pass "this" in mySignal but it doesn't seem to work...

[Zlatomir]

What problem do you want to solve?

I don't understand why do you need the button in there, the button emitted a signal with a QString parameter, so in there you use that, or recode that signal to transmit what you need.

[tbscope]

There are two solutions:

1. Use QSignalMapper
2. Use the sender() function

[SixDegrees]

If you think you need to know what object sent the signal, it's usually a sign that you need to rethink your design. You're coupling the recipient to the sender, requiring one to have explicit knowledge of the other. Normally, this is not a good thing; it violates the encapsulation principles of OO design, and can potentially create maintenance headaches in the future, when the internal details of an object change.

As noted above, there are ways to make this work, but take a moment and consider whether you really need to do this.

[dennis]

There are two solutions:

1. Use QSignalMapper
2. Use the sender() function

Thanks sender() worked, I then used dynamic_cast<buttonClass*>(sender()) to get the button reference, whats the difference between dynamic_cast and any other cast?

If you think you need to know what object sent the signal, it's usually a sign that you need to rethink your design. You're coupling the recipient to the sender, requiring one to have explicit knowledge of the other. Normally, this is not a good thing; it violates the encapsulation principles of OO design, and can potentially create maintenance headaches in the future, when the internal details of an object change.

Doesn't that depends on what your trying to do? I mean if your placing a dynamic number of items in a tab widget you probably want to know which of those item that actually sent you a signal, from my experience with other languages you pass the event to the event listener (slot) and then fetch the class reference from there. But in Qt (not sure if its the same in regular c++) you don't pass the event.

[tbscope]

Thanks sender() worked, I then used dynamic_cast<buttonClass*>(sender()) to get the button reference, whats the difference between dynamic_cast and any other cast?

First, try looking it up in a c++ book or on google.

Suppose you have a cube and a circular hole. You can't just push the cube through the round hole.
When you use a dynamic cast, you take a sledge hammer and whack the cube through the round hole. The result is that the cube went through the hole and it now resembles somewhat like a cylinder.
A static cast first looks at what both things are, a cube, and a round hole... hmmm, this isn't going to work, thus it will do nothing unless both objects are compatible

After that, you get in the weird quantum world with some special casts where one object can be in two states at once ;-)

In your example, I personally think it would not be a good idea to use a dynamic cast. I would use a static cast, and see if the object exists at all before proceeding. Hence, this is why most people try to avoid using sender() at all.

You could use a subclass, and create your custom signals that pass a pointer to the object too (or something else to identify a specific object). See also QSignalMapper

[dennis]

Thanks for taking you time to explain it to a newbie like me =)

[Zlatomir]

@tbscope: You reversed the casts

static_cast is similar to the C style cast and can be applied to just about anything. static_cast would be used when you are certain of the types in question.

dynamic_cast can only be used with pointers and references. On failure to cast, a null pointer is returned. dynamic_cast is generally used when resolving pointers to classes used in inheritance where you want to make sure the pointer you are casting is of the expected type.

[tbscope]

Ohh dear :-)

I should practice what I preach, read a c++ book.
I blame the warm weather here.

[Zlatomir]

@tbscope: hahahaha, nice

And now seriously, really nice comparison with the cube and a round hole! I think you should edit the post, because the comparison is awesome (too bad we don't have thumbs-up smiley)