gotnewmessage() signal does not emit after sendmessage() signal
-
@fari35
You're going to have show code for anyone to comment. In itself the fact that you changed howsendmessage()is sent/connected cannot affect something not being able to emit its own message.Try to show just the relevant bare-bones. We probably don't need to see the send message side, but do we do need to see (a) confirmation that the thread's slot is called from the send message and (b) how the thread does its
emit gotnewmessage()and (c) how that emitted signal is connected to the slot which should act on it. Put inqDebug()s to prove what's going on! -
@fari35
You're going to have show code for anyone to comment. In itself the fact that you changed howsendmessage()is sent/connected cannot affect something not being able to emit its own message.Try to show just the relevant bare-bones. We probably don't need to see the send message side, but do we do need to see (a) confirmation that the thread's slot is called from the send message and (b) how the thread does its
emit gotnewmessage()and (c) how that emitted signal is connected to the slot which should act on it. Put inqDebug()s to prove what's going on! -
@fari35
You're going to have show code for anyone to comment. In itself the fact that you changed howsendmessage()is sent/connected cannot affect something not being able to emit its own message.Try to show just the relevant bare-bones. We probably don't need to see the send message side, but do we do need to see (a) confirmation that the thread's slot is called from the send message and (b) how the thread does its
emit gotnewmessage()and (c) how that emitted signal is connected to the slot which should act on it. Put inqDebug()s to prove what's going on! -
@JonB I have now attached my whole code in the question. Can you please tell me what is wrong here?
@fari35
Too much for me, and I've done my bit. You should cut down the code to make it minimal and putqDebug()statements in to see what is/is not getting called.As a separate matter, get rid of old-style
SIGNAL/SLOT()macros and always use new style. You presently have a mixture. -
@aha_1980 @kshegunov @Christian-Ehrlicher Do you have anyidea about this?
-
I did not look what the code really does but tcpSocket is created in the wrong thread. You must create it inside run() so it's created in the new thread.
-
I did not look what the code really does but tcpSocket is created in the wrong thread. You must create it inside run() so it's created in the new thread.
@Christian-Ehrlicher ok I have corrected that. Can you please tell me why gotnewmessage() is not working after sendmessage() signal is emmited from windows class?
-
Hi,
@fari35 said in gotnewmessage() signal does not emit after sendmessage() signal:
class fserver : public QTcpServer,public threadobj
Why the double heritage ?
-
Hi,
@fari35 said in gotnewmessage() signal does not emit after sendmessage() signal:
class fserver : public QTcpServer,public threadobj
Why the double heritage ?
-
This is not how it works. Please check the threaded fortune server example if you really want to use threads.
In any case, the way you use multiple inheritance is wrong.
-
This is not how it works. Please check the threaded fortune server example if you really want to use threads.
In any case, the way you use multiple inheritance is wrong.
@SGaist Actually that's not the problem. The problem is that it is emitting gotnewmessage() signal until I don't click send button in mainwindow class to emit sendmessage() signal, but once sendmessage() signal is emmitted gotnewmessage() signal doesn't emit
-
That will be part of the problem at some point because it makes your code messy.
In any case, you have an issue with the socket creation as it's not done in the correct thread.
You should really clean your implementation. It will make your code easier to manage and debug.
-
That will be part of the problem at some point because it makes your code messy.
In any case, you have an issue with the socket creation as it's not done in the correct thread.
You should really clean your implementation. It will make your code easier to manage and debug.
-
That will be part of the problem at some point because it makes your code messy.
In any case, you have an issue with the socket creation as it's not done in the correct thread.
You should really clean your implementation. It will make your code easier to manage and debug.
-
That will be part of the problem at some point because it makes your code messy.
In any case, you have an issue with the socket creation as it's not done in the correct thread.
You should really clean your implementation. It will make your code easier to manage and debug.
-
Because there's no reason for that to happen. You just connected a signal to another signal.
Excuse me for being blunt but: your current code is a mess. Your architecture is wrong on several levels. You seem to want some kind of threaded server inside a GUI while also making it its own client but without any connection.
As I already suggested, if you really want to use threads (and you really don't at this stage), read the threaded fortune server example.
Keep things clearly separated. Have one server component, then build your GUI to use that component. Look for aggregation VS inheritance.
