Block GUI when waiting for QTcpSocket data

[FredT]

Hello everyone,

I am writing a program to interact with a network-based API using Qt. The interaction with the API is made with XML messages (both queries and results)

I implemented the communication and data processing in a class in a shared library project and I have a QMainWindow in which the user can enter the connection details. When clicking on the connect button, the following should happen: 1. An instance of the connecting class is created. 2. A connection message is sent to the API to get the session ID. The answer is parsed and a session ID is stored in the class instance. 3. A message is sent to the API the get some field information. The XML is then parsed to extract the required field information to get data from the API. 4. Another message is sent to get the data matching the fields. The XML answer is then parsed and stored in a data structure for processing. 5. The data is then processed and finally displayed to the user.

I made a simple console program to test the library and it is working fine - no message is sent before all the data from the previous message has been processed. However, when I implement the same process in a QMainWindow instance, no wait occurs and messages are sent one after another without waiting.

How can I block the GUI thread to wait for full processing before sending the next message?

Thanks

PS: The program I am working on is an internal tool at my company and the users will be mostly me (and maybe, maybe, one or two other persons).
PPS: It is a re-post from my stack overflow question: http://stackoverflow.com/questions/38900091/block-gui-when-waiting-for-qtcpsocket-data

[kshegunov]

@FredT
Hello,

You can start a local event loop, but this is discouraged. If you still insist on doing it:

QEventLoop loop;
QObject::connect(sender, &SenderClass::signal, &loop, &QEventLoop::quit);
loop.exec();

Where sender is a QObject that will signal the event loop to quit, and the SenderClass::signal() is the signal that should be emitted and will stop the event loop's waiting.

Kind regards.

[VRonin]

I agree with stack overflow. Your design is flawed. The state machine behind the communication should not depend in any way on the interface