slots with arguments

[marco.stanzani]

is this legal? I can compile but i wonder if this is bad practice or, even worse, suited for run time bugs


connect(mTcpSocket, SIGNAL(connected()), this, SLOT(sendMsg(mTcpSocket)));

connect(pTcpSocket, SIGNAL(connected()), this, SLOT(sendMsg(pTcpSocket)));
...
void ecmqMfgClient::sendMsg(QTcpSocket *tcpSocket)
{
QByteArray block;
QDataStream out(&block, QIODevice::WriteOnly);
out.setVersion(QDataStream::Qt_4_1);
out << this->Cli2SvrMsg.dutId;
out << this->Cli2SvrMsg.opCode;
out.device()->seek(0);
tcpSocket->write(block);
tcpSocket->waitForBytesWritten();

}


i.e. can i associate to the same signal of two different QTcpSocket to the same slot but with different parameters (the target socket but also others)?
QTcpSocket is event driven so i do not see any danger for concurrency, right?

not sure this is really a newbie question, hope to get less severe reply from somebody ;-)

thanks much

[high_flyer]

is this legal?
No.
See http://doc.qt.nokia.com/latest/signalsandslots.html for details.

can i associate to the same signal of two different QTcpSocket to the same slot?
Yes you can.

QTcpSocket is event driven so i do not see any danger for concurrency, right?
Huh?
Explain what you mean.


not sure this is really a newbie question,
Yes it is.

[wysota]

QTcpSocket is event driven so i do not see any danger for concurrency, right?
This has nothing to do with event-driven architecture. Your slot has to be reentrant if you wish to call it from different threads. If you wish to call it from the same thread, unless you enter the event loop inside the slot, it doesn't even have to be reentrant.

[marco.stanzani]

No.
See http://doc.qt.nokia.com/latest/signalsandslots.html for details.

but i see in the posted URL there are slots with arguments (i cannot see the connect in this example, though)


public slots:
void display(int num);
void display(double num);
void display(const QString &str);

so what's wrong in my code exactly (suppsoed that sendMsg is re-entrant?)
thanks

[FelixB]

slots can have arguments, of course. But you cannot set these arguments by yourself in the connect-statement. the arguments must match the signature of the connected signal. you can do this:


connect(objectA,SIGNAL(somethingHappended(const QString&)), objectB, SLOT(doSomething(const QString&)));

in this case, the signal "somethingHappended" has an argument which is automatically passed to "doSomething".

[marco.stanzani]

this is crystal-clear! thanks much!
indeed it ws not clear to me from the URL what 'signature' means.

it looks like i can achieve the goal by using the QObject::sender method to discern which emitter caused the slot invocation


connect(mTcpSocket, SIGNAL(connected()), this, SLOT(sendMsg());
connect(pTcpSocket, SIGNAL(connected()), this, SLOT(sendMsg());
...
void myClass::sendMsg()
{
QByteArray block;
QDataStream out(&block, QIODevice::WriteOnly);
out.setVersion(QDataStream::Qt_4_1);
out << this->Cli2SvrMsg.dutId;

if(sender== pTcpSocket)
out<<this->Cli2SvrMsg.opCode=P_OPCODE:
if(sender== mTcpSocket)
out<<this->Cli2SvrMsg.opCode=M_OPCODE:

sender()->write(block);
sender()->waitForBytesWritten();

}

this will infringe 'the object-oriented principle of modularity. However, getting access to the sender might be useful when many signals are connected to a single slot." according to http://doc.qt.nokia.com/latest/qobject.html#sender, which i don care since i am on the top level of my application
i also this Warning "... the return value of this function is not valid when the slot is called via a Qt::DirectConnection from a thread different from this object's thread. Do not use this function in this type of scenario." but i think this si not the case (it is autoconnection)
ciao