[Solved] Signal and Slot not connecting for some reason

Endless

I like the signal/slot system and use it quite a bit, but I'm completely stumped on this issue. Look at the following code snippet:
@
faultLogScreen = new FaultLogWindow();
myStackedWidget->addWidget(faultLogScreen);
connect(faultLogScreen, SIGNAL(requestFaultCode(QString*, int)), this, SLOT(deliverFaultCode(QString*, int)));
connect(updateDisplayTimer, SIGNAL(timeout()), faultLogScreen, SLOT(updateDisplay()));
connect(faultLogScreen, SIGNAL(activateScreen(int)), this, SLOT(setCurrentScreen(int)));
@
Pretty simple and straightforward. I know that the two of the above signal/slot connections work: updateDisplay and setCurrentScreen. For some reason I don't understand, the deliverFaultCode slot is not being connected. I call it like this in the faultLogScreen code:
@
emit requestFaultCode(faultStringPtr, sysPos);
@

In the function for the deliverFaultCode slot, I have a qDebug() statement that prints out a little message letting me know it gets there, but I never see the message. I know the signals and slots are being defined correctly in the hpp files because everything compiles fine. What am I missing?

koahnig

Did you check out the output screen?
It tells you when and what is not correct.
You can also check the return value for connect for testing if connection failed.

Endless

Do you mean the Application Output tile inside of Qt Creator? That's where I see text from other qDebug() messages.
How and where do I check the return value for connect for testing?

dvdk

yes
connect returns true on success (line 3 in your code)

I also don't think the compiler complains if you have a typo in a signal or slot in the connect line

andre

Small side note: why are you passing QString* around? QString is very cheap to copy, so you can use it as a simple value.

To check the connect itself, do something like this:
@
bool ok = connect(... the connect stuff);
Q_ASSERT(ok);
@

Endless

Yes, I understand what you're getting at. So, I added [if(connect(....)) qDebug() << "Accepted";] I see that all 3 are being accepted when I look at the application output pane.

andre

So, that means that the connect is ok, leading to the idea that the emit is not happening.

Endless

The deliverFaultCode slot returns a string that contains the text for the description of the fault code. Since I didn't think a slot could "return" anything, I used a QString * to be able to look at the value that was set in the deliverFaultCode slot.
I added the Q_ASSERT(ok) and don't see any warning message in my application output.

Endless

I call the emit when I populate a QTableWidget. The rest of the table's being populated, so the emit is definitely being called:
@
faultEntry[index].faultDate = new QTableWidgetItem();
faultEntry[index].faultDate->setText(fault[skipLines].dateString);
faultEntry[index].faultDate->setTextAlignment(Qt::AlignCenter);
logTable->setItem(index, 0, faultEntry[index].faultDate);
faultEntry[index].faultTime = new QTableWidgetItem();
faultEntry[index].faultTime->setText(fault[skipLines].timeString);
faultEntry[index].faultTime->setTextAlignment(Qt::AlignCenter);
logTable->setItem(index, 1, faultEntry[index].faultTime);
faultEntry[index].faultCode = new QTableWidgetItem();
faultEntry[index].faultCode->setText(fault[skipLines].codeString);
faultEntry[index].faultCode->setTextAlignment(Qt::AlignCenter);
logTable->setItem(index, 2, faultEntry[index].faultCode);
sysPos = fault[skipLines].codeString.toInt(&ok, 10);
emit requestFaultCode(faultStringPtr, sysPos);
faultEntry[index].faultDesc = new QTableWidgetItem();
faultEntry[index].faultDesc->setText(faultString);
faultEntry[index].faultDesc->setTextAlignment(Qt::AlignCenter);
logTable->setItem(index, 3, faultEntry[index].faultDesc);
@

andre

[quote author="Endless" date="1333117644"]1) The deliverFaultCode slot returns a string that contains the text for the description of the fault code. Since I didn't think a slot could "return" anything, I used a QString * to be able to look at the value that was set in the deliverFaultCode slot.
[/quote]

True, but using a pointer to return a value is dangerous at best. What happens if there are multiple listeners to the signal? And if there are not/can not be, you might as well use a direct method invokation, which would free you from the issue completely.

[quote]
2) I added the Q_ASSERT(ok) and don't see any warning message in my application output.[/quote]

[quote author="Endless" date="1333117793"]I call the emit when I populate a QTableWidget. The rest of the table's being populated, so the emit is definitely being called:[/quote]
I guess it is time to fire up your debugger, set a breakpoint at the emit statement, and step into what's going on there...

Endless

Where can I read about or see examples of direct method invocation? Another way of passing data would get me away from this signal/slot connection that doesn't work. My debugger freezes up the system not long after my application starts.

andre

Just a normal method call, I mean by that.