[solved]Dynamically updating the screen at the client side as soon as data collected from the server side
-
One option is to create your own MyBackgroundThread class and make it inherit from QThread. Then simply re-implement the run() method and put the code there that you want to run in the background. Then, from the "main" thread, create an instance of the MyBackgroundThread and call start() to make the thread start. Do not call run() from the "main" thread directly, because this would run the run() method inside the "main" thread. Instead, calling start() will create a new thread in which the run() method will be run. Also see the code I posted above!
--
Also don't forget this:
http://qt-project.org/doc/qt-4.8/moc.html -
@MuldeR
Sir,
what i thought of doing is in thread class creating data member of mainwindow class type and in run method is passing calling the function of mainwindow object where all tcp realted connection and receiving data from the server will take place, Is it possible? -
The creation of your GUI widgets and all (direct) access to your GUI widgets necessarily has to happen in "main" thread! At the same time, setting up your TCP connection, waiting for new messages to arrive over this connection as well as processing those messages can happen in another ("background") thread. That's why you would normally make your "background" thread emit Signals whenever new information is available! These signals will be picked up by the "main" thread in a suitable Slot function, from which you can access/update any GUI widgets that need to be updated. The queued connection type of Qt does exactly that: It processes signals (i.e. calls slot functions) in the context of the thread to which the target object belongs, rather than in the context of the thread which emitted the signal. Again, please see my example above for details on how you can do all that...
-
@Mulder
hello sir,
Now problem with the thread is solved . I am able to connect background and front end through signals and slot, but problem is regarding with the tcpsocket and tcpserver, when i put tcpsocket->connecttohost() inside run,
i am getting the run time error
QAbstractSocket::connectToHost() called when already looking up or connecting/connected to "127.0.0.1" and after that program unexpectedly ends I am not sure of where to put this line of code
tcpSocket->connectToHost(); i even removed forever loop inside and tried but it was not of any use .. please help
thanks :) -
[quote]i am getting the run time error QAbstractSocket::connectToHost() called when already looking up or connecting/connected to “127.0.0.1” and after that program unexpectedly ends I am not sure of where to put this line of code[/quote]
What is "the" run time error? What error do you get exactly?
Also, the connection would be established before the loop, inside the loop (if connection succeeded) you read/process the incoming messages, but do NOT re-connect every time...
Anyway, here is a small QTcpSocket example found on the net:
http://pastie.org/private/x8egwwqjldjno3c5zvpda -
@Mulder,
thank you sir for the link.. that was really helpful,
now i am not getting the above error, now the new run time error is
Cannot create children for a parent that is in a different thread.
specially comes when i write this part of the code
socket =new QTcpSocket(this); that too comes specially because i am passing thread object("this" parameter) if i remove or won't in create the socket at run time the socket object is not identified itself, i have seen many people getting the same error, still not finding the rite answer. -
MuldeR: Why a background thread? The socket classes are asynchronous, so why not do this in the UI thread?
-
[quote author="Tobias Hunger" date="1364115931"]MuldeR: Why a background thread? The socket classes are asynchronous, so why not do this in the UI thread?[/quote]
It's of course only one possible way to do it. If he needs to decode/process the "messages" in some way or if he needs to assemble payload from multiple "messages" that are incoming over TCP connection or if most of the messages won't change the user-visible state, then it might be better to do the messages processing + program state update in a background thread and only send a Signal to the GUI thread when a new event (that the user needs to know about) has occurred. Keeps the GUI thread free from "lengthy" calculations. Also gives a better GUI/View vs. Model/Businesslogic separation. But yes, all that may be "overkill" for small apps...