[Solved] Signal and Slot not connecting for some reason
-
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?
-
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. -
-
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?
-
-
- 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
-
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);
@ -
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.
-
So, that means that the connect is ok, leading to the idea that the emit is not happening.
-
-
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.
-
-
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);
@ -
[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... -
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.
-
Just a normal method call, I mean by that.