[Solved] Signal and Slot not connecting for some reason

[Endless]

1. Do you mean the Application Output tile inside of Qt Creator? That's where I see text from other qDebug() messages.

2. How and where do I check the return value for connect for testing?

[dvdk]

1. yes
2. 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]

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.

2. 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.