QTimer::start(0) vs QThread, which one to choose?
-
I am reading data from a device with
QTimerat a specified interval. I want to read its status continuously instead with a time interval. Passing 0 tostart()function ofQTimermake it work continuously. Now how I choose between them? Which class should I use?
And when i lookQThreadexamples, they inherited their classes fromQObject. I need thread in myQWidgets. Do i need to create external class for threading functions? -
I am reading data from a device with
QTimerat a specified interval. I want to read its status continuously instead with a time interval. Passing 0 tostart()function ofQTimermake it work continuously. Now how I choose between them? Which class should I use?
And when i lookQThreadexamples, they inherited their classes fromQObject. I need thread in myQWidgets. Do i need to create external class for threading functions? -
@masa4 If you really need to read the status continuously (why is that needed?) without blocking the main thread then you will need to use a thread. But the question is: why do you need to read the status that often?
@jsulm Actually my main goal is, when the data changed, I am changing somehing in ui(blocking some checkbox, changing value of checkboxes etc.). I thought, if data is changed and i still didnt block a dedicated checkbox(which writes data to device), the program maybe crash or works buggy. So i want to read its state as much as possible.
Can QTimer block UI?
-
@jsulm Actually my main goal is, when the data changed, I am changing somehing in ui(blocking some checkbox, changing value of checkboxes etc.). I thought, if data is changed and i still didnt block a dedicated checkbox(which writes data to device), the program maybe crash or works buggy. So i want to read its state as much as possible.
Can QTimer block UI?
@masa4 said in QTimer::start(0) vs QThread, which one to choose?:
So i want to read its state as much as possible
Doesn't sound like the right solution: you will have high CPU load just to get the status and there still can be a delay between changing the data and changing the UI. Better would be if your device would notify your application if something changed and making your code robust, so it does not crash.
"Can QTimer block UI?" - well, if it triggers a slot at high rate then the event loop will not be blocked, but your main thread will be very busy, so the UI may react slowly or even stop reacting at all.
-
@masa4 said in QTimer::start(0) vs QThread, which one to choose?:
So i want to read its state as much as possible
Doesn't sound like the right solution: you will have high CPU load just to get the status and there still can be a delay between changing the data and changing the UI. Better would be if your device would notify your application if something changed and making your code robust, so it does not crash.
"Can QTimer block UI?" - well, if it triggers a slot at high rate then the event loop will not be blocked, but your main thread will be very busy, so the UI may react slowly or even stop reacting at all.
@jsulm Actually I am using a external class's methods&members for reading data from device(serial communication). I am not able to modify the codes and this code does not use qt so no signal mechanism inside it. But when i look codes, there is just read/write functions to get data and write data to device, and a thread to check if device still connected or not. So i am unable to know the state of data on device until i read from it.
Long story short, i am unable to modify device to inform me when its state changed. So what I understand, QThread is better option over QTimer. If I am wrong, correct me. And do you have any idea about my second question? Do I need to create an external class that inherits from QThread or QObject to use thread mechanism? Cant I directly use it in my widget class?
-
@jsulm Actually I am using a external class's methods&members for reading data from device(serial communication). I am not able to modify the codes and this code does not use qt so no signal mechanism inside it. But when i look codes, there is just read/write functions to get data and write data to device, and a thread to check if device still connected or not. So i am unable to know the state of data on device until i read from it.
Long story short, i am unable to modify device to inform me when its state changed. So what I understand, QThread is better option over QTimer. If I am wrong, correct me. And do you have any idea about my second question? Do I need to create an external class that inherits from QThread or QObject to use thread mechanism? Cant I directly use it in my widget class?
@masa4 If you want to use threads in Qt you should use worker object approach: https://wiki.qt.io/QThreads_general_usage
-
Maybe your external class has a way to register a callback. In this case you could write your own callback function to just emit the proper signal. This would be the best solution.
QThread is really complicated to get right. And, no, you cannot use it directly inside your widget. The widget needs to run in the main thread and the thread, well it's its own thread. So, this needs to be a separate class. However, you can manage the thread object through your widget object (if done right, which, again, is complicated).
Most likely your monitor updates at a refresh rate of 60 Hz. This means that only every (approximately) 16 ms will the GUI change. And even this is a lot faster than a normal human sitting in front of the screen is able to register the change. So, a timer is plenty enough to update the GUI properly.
-
not able to spontaneously receive "state changed" means you must implement "polling". that's what it is called. Polling is a necessary evil of event driven architectures when the device is, as you say, not sending status changes, but polling is usually hidden from the user by the framework.
You need to decide with what resolution/time-interval to poll the device and implement it using the timer, not a thread. threading complicates things and is unnecessary.
if you are truly convinced taht you must constantly poll (as fast as the cpu clock allows for) then accept that qt is not the correct framework for your task, as pegging the cpu will create real UI latency problems. Qt is designed for UI applications, not real-time processing.
