Using QUdpSocket within a QThread

[marcel]

It was suggested that I may need a Q_OBJECT in the Thread class; I didn’t think so because I’m not using a widget (may be an incorrect assumption on my part). I put it in the code and got linker errors:

Not only QWidget sibclasses but all classes that use/implement signals and slots have to have the Q_OBJECT macro in order to be processed by moc. So, it is mandatory in your case.

"Undefined reference to vtable for CHostIFReceive."

My understanding is that it thinks I’m using a virtual object that hasn’t been declared, I didn’t think I was.

Do you implement two classes in the same cpp? There was a similar problem on the forum, still unsolved unfortunately. Try splitting the declarations and implementations for classes containing the Q_OBJECT macro.

2) Another suggesting was that I should not create the QUpdSocket in the QThread constructor but in the run() method (all the examples I’ve seen have it in the constructor). I got the following runtime errors:

"QObject can not create children for a parent that is in a different thread.
(Parent is QThread(0xbfefb140), parent’s thread is QThread(0x9e9c2e8), current thread is QThread(0xbfefb140)
Object::connect: No such slot QThread:rocessPendingDatagrams."

You'll have to post the thread code for this. Probably something got mixed up.
It might be that the worker thread object lives in the GUI thread. If you move it to itself after it is started could solve the problem.

Final suggestion was to make sure that I pass in Qt:irectConnection as the fifth parameter for the connect() method. That had no affect.

If the socket lives in the worker thread there will be no need to specify the connection type. It will default to direct.

Also, make sure you start the event loop in the thread with exec, otherwise thread slots won't work.

[jacek]

If the socket lives in the worker thread there will be no need to specify the connection type. It will default to direct.

On the contrary. The receiver, i.e. QThread, lives in the GUI thread and the socket lives in the worker thread, so the connection will be queued and all signals will land in GUI thread's event queue.

[marcel]

Yes but you can always move the QThread object from to GUI thread to the worker thread to solve this. This way connect will default to Qt:irectConnection and the slot gets executed by the worker thread.

Or, as you said, can leave it like it already is and force a direct connection.
EDIT: both approaches work, but I prefer the one with changing the object's affinity. Don't really know why, though...

[jacek]

Yes but you can always move the QThread object from to GUI thread to the worker thread to solve this. This way connect will default to Qt::DirectConnection and the slot gets executed by the worker thread.

Of course, but won't that create problems after the thread stops? You will end with an object that lives in a non-existent thread.

[marcel]

You're right! Never thought of that.
I wonder if there's a solution for this. Maybe the finished() signal can be used to delete the QThread object.
Indeed, changing affinities sucks.

[db]

JPN, Thanks for walking me through the change with explanations... I did miss the qmake and of course removing the parent in the instaniation help also.

Marcel, Jacek, Thanks for your inputs also. I got lost in some of the stuff but being a newbie I'm sure it will eventually make sense.

also my bad about the 2 threads but I thought that I was starting a new topic with the QUdpSocket so...

Again, thanks guys