General and Desktop

When you start a QThread it will run its own event loop. doStuff is the first slot that is executed in that event loop. However, by your design, the while-loop will block the event loop of this thread. The stop signal will thus never be executed as stop will be executed in the context of the receiver, i.e. the event loop of that other thread and not the main event loop. Here are a few ideas how you could solve your problem: Have the stop_action connect to a slot in MainWindow that directly calls self.worker.stop(). This will be executed in the main event loop, so blocking in the other thread is not a problem. Someone might mention that Worker.stopped is not an atomic variable. As long as you don't want to have an immediate reaction this will not be a problem. The worker thread will pick up the change eventually. (Actually, you might even not notice any delay.) If you want to simulate an infinite loop inside the event loop of that thread, you can have a QTimer running with a timeout of 0s. This will constantly put a call to the same slot into your event loop. Still, the stop signal has a chance to slip in between and you'll have a chance to kill that timer. As you said before you want to send data to the worker thread through a signal-slot connection. This approach would be the preferred way. Only do work in the worker thread when you have new data. Just call a slot in the worker thread (through a signal) with the new data and do the work. Afterwards the worker thread can idle to wait for new data. No need to have a loop running.

BTW, I think QCoreApplication::instance() is a mouthful. There are two shorter versions for that: qApp and qGuiApp. These will cast the instance to QApplication and QGuiApplication, respectively.

@Christian-Ehrlicher qt version 5.4.0. the mmi interface is done using the qt creator, drag and drop. void MainWindow::on_down_slot() { int iIndex = ui->ui->comboxbox1->currentIndex() - 1; ui->comboxbox1->setCurrentIndex(iIndex); } so when down key is detected, the above slot will be executed.

I should have specified that I am trying to log in multiple formats simultaneously. My bad. From your link: "The first version of the -o option (-o filename,format), may be repeated in order to log test results in multiple formats, but no more than one instance of this option can log test results to standard output." So, if I want to log to a file and stdout simultaneously, I believe this is the only option.

In that case and as I already wrote before, you should implement a proper web service to access the data from your desktop application. You then use QNetworkAccessManager to query that service.

Hi and welcome to devnet, You already have QTextEdit, use QFile to load and store your data.

Hi, Go with the usual: single responsibility. If a widget shall handle a particular aspect then keep it separated with a clean API so can also make it testable. For the models, it will highly depend on what you want to access and how you need to interact with it.

@JonB , found it missing ";" on the last statement before the "}"

@VRonin I cant believe I made this rookie mistake. Thank you so much. Cant believe it lol

Hi and welcome to devnet, Qt 5.6.3 is really outdated. You should consider to either move to current latest version which is 5.14.2 or if you want to stay in LTS 5.12.8. Qt 5.6.3 still uses OpenSSL 1.0, do you have that one on your Linux system ?

You're very welcome.

Add my custom data access methods. (custom get/set functions). This also requires the delegate to get tied up with the model. I'm a fan of solution 1 but, in the interest of pragmatism, I'd say use the path that is less painful to implement for you. P.S. Classes that include the Q_GADGET macro are already registered metatypes so you can go down that route as well

@mrjj Hello, Thanks for your reply! Meanwhile I've made something maybe a little bit strange. I've created a configuration class which is retrieving the request data in a Json file (might not be the best data format to store a configuration variables) and store it into a member variable. Then I've get this value in the class that need it inside the constructor. Those code samples will be moremeaningful: configuration.h: public: explicit configuration(QObject *parent = nullptr); QString getApiUrl(); private: QString m_apiUrl; void init(); configuration.cpp: configuration::configuration(QObject *parent) : QObject(parent) { init(); } QString configuration::getApiUrl() { return m_apiUrl; } void configuration::init() { QString config; QString configFile = QDir::currentPath() + QDir::separator() + "configuration.txt"; QFile file(configFile); if(!file.open(QIODevice::ReadOnly)) { qDebug() << file.errorString(); } config = file.readAll(); file.close(); QJsonDocument configJson = QJsonDocument::fromJson(config.toUtf8()); QJsonObject configObject = configJson.object(); m_apiUrl = configObject["apiUrl"].toString(); } http_service.h: private: configuration *config = new configuration(this); QNetworkAccessManager nam; QString m_apiUrl; http_service.cpp: httpService::httpService(QObject *parent) : QObject(parent) { m_apiUrl = config->getApiUrl(); } But I think I'll do has you say, it will be much cleaner. Once again thank you all for your comments and replies.

@viniltc Messages that you print by qDebug() can be disabled by adding this to the .pro file DEFINES += QT_NO_DEBUG_OUTPUT

Thanks, I've signed up and asked again there.

How to debug this kind of problem? Qt app is frozen and memory leak will cause the computer to crash eventually. Valgrind will not help.

There is no alternative to loading the entire document, modifying the element and save it down again

Thank you @SGaist , filed a bug report.

Thank you guys for your feedback. Yes, I think the problem is probably in the Test function. I know that also Qt is switching to CMake, but I wonder if there is a temporary solution to fix this problem in some other way