QObject::connect returns false
-
wrote on 26 Apr 2022, 11:36 last edited by SPlatten
Under what scenario will a connect return false?
I have two objects both are valid, I create the signalling object:
clsTimeEmu* pobjEmulator(new clsTimeEmu);
I create the receiving object that has the slot:
clsTimeSync* pobjService(new clsTimeSync);
Then the connection:
bool blnRc(QObject::connect(pobjEmulator, SIGNAL(epoch(long)), pobjService, SLOT(updateTime(long))));
blnRc contains false. What could explain this?
Qt version in this case is 4.8.4
-
@SPlatten your derived class will need the Q_OBJECT macro as well, if it defines slots/signals
-
Under what scenario will a connect return false?
I have two objects both are valid, I create the signalling object:
clsTimeEmu* pobjEmulator(new clsTimeEmu);
I create the receiving object that has the slot:
clsTimeSync* pobjService(new clsTimeSync);
Then the connection:
bool blnRc(QObject::connect(pobjEmulator, SIGNAL(epoch(long)), pobjService, SLOT(updateTime(long))));
blnRc contains false. What could explain this?
Qt version in this case is 4.8.4
@SPlatten said in QObject::connect returns false:
blnRc contains false. What could explain this?
The connection is invalid if QObject::connect was not able to find the signal or the slot, or if the arguments do not match.
have you checked signal and slot declaration?
also, is the Q_OBJECT macro in both header files? -
Under what scenario will a connect return false?
I have two objects both are valid, I create the signalling object:
clsTimeEmu* pobjEmulator(new clsTimeEmu);
I create the receiving object that has the slot:
clsTimeSync* pobjService(new clsTimeSync);
Then the connection:
bool blnRc(QObject::connect(pobjEmulator, SIGNAL(epoch(long)), pobjService, SLOT(updateTime(long))));
blnRc contains false. What could explain this?
Qt version in this case is 4.8.4
-
Under what scenario will a connect return false?
I have two objects both are valid, I create the signalling object:
clsTimeEmu* pobjEmulator(new clsTimeEmu);
I create the receiving object that has the slot:
clsTimeSync* pobjService(new clsTimeSync);
Then the connection:
bool blnRc(QObject::connect(pobjEmulator, SIGNAL(epoch(long)), pobjService, SLOT(updateTime(long))));
blnRc contains false. What could explain this?
Qt version in this case is 4.8.4
wrote on 26 Apr 2022, 11:46 last edited by@SPlatten said in QObject::connect returns false:
What could explain this?
There are several possibilities:
- signals do not exist (or bad signature)
- slots do not exist (or bad signature)
Q_OBJECT
is missed- moc needs to be (re)run
- typo is signal/slot names
-
@J-Hilk , @JonB , the signal prototype in the class clsTimeEmu:
signals: void epoch(long lngTime);
The slot prototype in the class clsTimeSync:
public slots: void updateTime(long lngTimeNow);
wrote on 26 Apr 2022, 11:46 last edited by JonB@SPlatten
Nothing obviously wrong there then. Please put in theQ_ASSERT
s to make me happy?!And follow all of the suggestions from @KroMignon above!
-
@J-Hilk , @JonB , the signal prototype in the class clsTimeEmu:
signals: void epoch(long lngTime);
The slot prototype in the class clsTimeSync:
public slots: void updateTime(long lngTimeNow);
@SPlatten is this potentially cross thread ?
or more in general, the
long
typdef may not be correctly registered with the meta system.you could use qint32, that should work.
-
@SPlatten
Nothing obviously wrong there then. Please put in theQ_ASSERT
s to make me happy?!And follow all of the suggestions from @KroMignon above!
wrote on 26 Apr 2022, 11:49 last edited by@JonB , so the source now reads:
Q_ASSERT(pobjEmulator); Q_ASSERT(pobjService); bool blnRC(QObject::connect(pobjEmulator, SIGNAL(epoch(long)) ,pobjService, SLOT(updateTime(long))));
Built and run, no assertions, blnRC is false.
-
@SPlatten is this potentially cross thread ?
or more in general, the
long
typdef may not be correctly registered with the meta system.you could use qint32, that should work.
wrote on 26 Apr 2022, 11:50 last edited by@J-Hilk , no, not at the moment, this is just simple test code, nothing complex at all....just literally creating instances of each, call to connect and that is it.
-
@SPlatten is this potentially cross thread ?
or more in general, the
long
typdef may not be correctly registered with the meta system.you could use qint32, that should work.
wrote on 26 Apr 2022, 11:50 last edited by@J-Hilk said in QObject::connect returns false:
or more in general, the long typdef may not be correctly registered with the meta system.
long
, really?? -
@J-Hilk said in QObject::connect returns false:
or more in general, the long typdef may not be correctly registered with the meta system.
long
, really?? -
@SPlatten is this potentially cross thread ?
or more in general, the
long
typdef may not be correctly registered with the meta system.you could use qint32, that should work.
wrote on 26 Apr 2022, 11:52 last edited by@J-Hilk said in QObject::connect returns false:
or more in general, the long typdef may not be correctly registered with the meta system.
But this would not affect to
connect()
call, only slot may not be called if sender and receiver not in same thread.For my comprehension of QObject signals/slots, connect() will only fail if no machting signal or slot signature are found in meta-data. Which are generated by moc.
-
wrote on 26 Apr 2022, 11:53 last edited by
I changed long to int just to be sure, same result.
-
@JonB , so the source now reads:
Q_ASSERT(pobjEmulator); Q_ASSERT(pobjService); bool blnRC(QObject::connect(pobjEmulator, SIGNAL(epoch(long)) ,pobjService, SLOT(updateTime(long))));
Built and run, no assertions, blnRC is false.
wrote on 26 Apr 2022, 11:53 last edited by@SPlatten said in QObject::connect returns false:
Built and run, no assertions, blnRC is false.
Just checking: how do you know that? I wouldn't trist that if you are only viewing in debugger, as I believe you sometimes do; are you actually outputting the variable's value?
-
@J-Hilk said in QObject::connect returns false:
or more in general, the long typdef may not be correctly registered with the meta system.
But this would not affect to
connect()
call, only slot may not be called if sender and receiver not in same thread.For my comprehension of QObject signals/slots, connect() will only fail if no machting signal or slot signature are found in meta-data. Which are generated by moc.
wrote on 26 Apr 2022, 11:53 last edited by@KroMignon I will look at the generated moc files, but as you can see from my posts the prototypes are identical.
-
@SPlatten said in QObject::connect returns false:
Built and run, no assertions, blnRC is false.
Just checking: how do you know that? I wouldn't trist that if you are only viewing in debugger, as I believe you sometimes do; are you actually outputting the variable's value?
-
@KroMignon I will look at the generated moc files, but as you can see from my posts the prototypes are identical.
wrote on 26 Apr 2022, 11:54 last edited by@SPlatten
Per @KroMignon, just start by emptying out your build output directory and doing a complete rebuild, just in case. Always start there when Qt gives you something "inexplicable" :) -
@SPlatten
Sorry, what's wrong with what?
My previous post was just expressing surprise to @J-Hilk thatlong
type might not be "registered with the meta system", but he knows more than I....wrote on 26 Apr 2022, 11:55 last edited by@JonB said in QObject::connect returns false:
My previous post was just expressing surprise to @J-Hilk that long type might not be "registered with the meta system", but he knows more than I..
For inter-thread communication, or in case of
Qt::QueuedConnection
, parameters needs to be copied. So QMeta needs to know how to create a copy of them. This is way all types needs to be registered. Some are already registered my Qt, some not ;) -
@JonB , I have a break point in the debugger after the connect and can see it contains false.
wrote on 26 Apr 2022, 11:55 last edited by@SPlatten said in QObject::connect returns false:
@JonB , I have a break point in the debugger after the connect and can see it contains false.
Noooo.
Like I said, print it out........
1/48