signal/slot not working
-
Insert a qDebug() before the
emitto be 100% sure.One more idea... this method isn't called once, is it? Because if it is called once, and your have a
break;in yourswitchthen only the first ack will triggerMSG_DISCOVERY_ACK, then it will break and never bother to check ifMSG_WIFI_SETUP_ACKis satisfied or not. -
Let's be 100% clear for everyone: because of your separate threads, these are queued-connection signals, right? So the slots won't be called during the
emits, only later on, and we're all clear about this, right?@sierdzio said in signal/slot not working:
Insert a qDebug() before the emit to be 100% sure.
Damn right, I'd have expected you to do this to make sure already!
-
Let's be 100% clear for everyone: because of your separate threads, these are queued-connection signals, right? So the slots won't be called during the
emits, only later on, and we're all clear about this, right?@sierdzio said in signal/slot not working:
Insert a qDebug() before the emit to be 100% sure.
Damn right, I'd have expected you to do this to make sure already!
@JonB said in signal/slot not working:
Let's be 100% clear for everyone: because of your separate threads, these are queued-connection signals, right? So the slots won't be called during the emits, only later on, and we're all clear about this, right?
Yes, they will be queued. Good point, that adds one, although rare, possibility: the event loop may be too busy to process the queue.
-
Sigh.
I really should never have become a programmer.
This was pure cockpit error on my part. Everyone feel free to negrate me.
And Jon, email me your postal address; I'll send you a bottle of the good stuff.
Sorry, everyone.
@mzimmers So, what was it, not be shy, we won't judge :D
I was about to suggest changing the argument of your signals to actual objects (not pointers or references) to force the compiler the acknowledge that copying has to be done, and that the lifetime of the objects do not interfere.
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
Do not despair :-) I'm pretty sure all of us here had spent a whole day (or 3...) looking for some nasty bug only to discover a missing semicolon :D
@sierdzio said in signal/slot not working:
Do not despair :-) I'm pretty sure all of us here had spent a whole day (or 3...) looking for some nasty bug only to discover a missing semicolon :D
very true, my personal favorite:
if(conditionA == true); callFunctionA();and callFunctionA() always being executed. Now days QtC warns you about it, but that wasn't always the case. Long days of debugging ....
-
@mzimmers So, what was it, not be shy, we won't judge :D
I was about to suggest changing the argument of your signals to actual objects (not pointers or references) to force the compiler the acknowledge that copying has to be done, and that the lifetime of the objects do not interfere.
@J-Hilk said in signal/slot not working:
@mzimmers So, what was it, not be shy, we won't judge :D
Ridiculously stupid. My Wifisetup object had:
this->done(0);at the end of a slot for a button push. Once upon a time, this was correct, but the protocol changed, so now we wait for a confirmation before exiting. (The code that I posted was part of this.) That's where the new done() is. Unfortunately, some doofus who shall remain nameless, forgot to remove the original one. So, the signal fired, but the object containing the slot had already been destroyed.
I guess I'm a little surprised that I don't get some kind of error/warning, but I guess Qt's OK with signals just disappearing into the bit bucket.
I was about to suggest changing the argument of your signals to actual objects (not pointers or references) to force the compiler the acknowledge that copying has to be done, and that the lifetime of the objects do not interfere.
This is probably a good idea for future reference. As an embedded software engineer, I often find resources to be somewhat limited, so I'm accustomed to rather parsimonious programming. I used pointers to save stack space, which is probably silly on a desktop.
-
@J-Hilk said in signal/slot not working:
@mzimmers So, what was it, not be shy, we won't judge :D
Ridiculously stupid. My Wifisetup object had:
this->done(0);at the end of a slot for a button push. Once upon a time, this was correct, but the protocol changed, so now we wait for a confirmation before exiting. (The code that I posted was part of this.) That's where the new done() is. Unfortunately, some doofus who shall remain nameless, forgot to remove the original one. So, the signal fired, but the object containing the slot had already been destroyed.
I guess I'm a little surprised that I don't get some kind of error/warning, but I guess Qt's OK with signals just disappearing into the bit bucket.
I was about to suggest changing the argument of your signals to actual objects (not pointers or references) to force the compiler the acknowledge that copying has to be done, and that the lifetime of the objects do not interfere.
This is probably a good idea for future reference. As an embedded software engineer, I often find resources to be somewhat limited, so I'm accustomed to rather parsimonious programming. I used pointers to save stack space, which is probably silly on a desktop.
@mzimmers said in signal/slot not working:
I guess I'm a little surprised that I don't get some kind of error/warning, but I guess Qt's OK with signals just disappearing into the bit bucket.
Yeah, except in cases where it bites (like this), it is quite convenient that you can delete QObjects and signal/slot connections are automatically removed.
-
@J-Hilk said in signal/slot not working:
@mzimmers So, what was it, not be shy, we won't judge :D
Ridiculously stupid. My Wifisetup object had:
this->done(0);at the end of a slot for a button push. Once upon a time, this was correct, but the protocol changed, so now we wait for a confirmation before exiting. (The code that I posted was part of this.) That's where the new done() is. Unfortunately, some doofus who shall remain nameless, forgot to remove the original one. So, the signal fired, but the object containing the slot had already been destroyed.
I guess I'm a little surprised that I don't get some kind of error/warning, but I guess Qt's OK with signals just disappearing into the bit bucket.
I was about to suggest changing the argument of your signals to actual objects (not pointers or references) to force the compiler the acknowledge that copying has to be done, and that the lifetime of the objects do not interfere.
This is probably a good idea for future reference. As an embedded software engineer, I often find resources to be somewhat limited, so I'm accustomed to rather parsimonious programming. I used pointers to save stack space, which is probably silly on a desktop.
@mzimmers said in signal/slot not working:
I guess I'm a little surprised that I don't get some kind of error/warning, but I guess Qt's OK with signals just disappearing into the bit bucket.
Not sure what you're surprised about? What do you want a warning for? (And I'm glad there isn't one.) As @shaan7 says, in Qt deleting the object used as the source of a signal or the destination of a slot in a
connect()means that connection is automatically removed with it, and thank goodness for that!If you ask me to give you a phone call when I wake up in the morning, and I have a heart attack and die during the night, or you die, either way no phone call gets made and we are all happy about it, without anyone sending a warning in the post :)
