So I am writing a program that displays each letter of a word for 1 second with a 1 second interval between the letters. (It's for a spelling exercise for grade 1). I am currently using the sleep function to "pause" the program for 1 second before it "updates" again. After that it displays the word for a second and then removes it. I repaint before the sleep function, else it does not seem to update in time.
Here is the basic function:
QString word = "apple";
QThread thread;
for(int i = 0; i < word.size(); i++)
{
ui->label1->setText(word[i]);
ui->label1->repaint();
thread.sleep(1);
ui->label1->setText("");
thread.sleep(1);
}
ui->label1->setText(word);
ui->label1->repaint();
thread.sleep(1);
ui->label1->setText("");
This works fine, except the program stops responding (even though I can see the correct output is still displaying) until the whole function is done executing then it works fine again. Is there another way I can accomplish this goal without using sleep? I am quite new to Qt.
Update I made. I made a new class that will handle the timer, but it does not seem to actually connect the signal and slot. Here is the .h file:
#ifndef TIMERDISPLAY_H
#define TIMERDISPLAY_H
#include <QTimer>
#include <QObject>
class TimerDisplay:public QObject
{
Q_OBJECT
public:
TimerDisplay();
public slots:
void expired();
private:
QTimer timer;
};
#endif // TIMERDISPLAY_H
and the .cpp file:
#include "timerdisplay.h"
#include <QDebug>
TimerDisplay::TimerDisplay()
{
connect(&timer, SIGNAL(timeout()), this, SLOT(expired()));
timer.setSingleShot(false);
timer.setInterval(1000);
timer.start();
}
void TimerDisplay::expired()
{
qDebug()<<"timer expired";
}
Use QTimer or QElapsedTimer if you need more precision.
main.cpp
#include <QTimer>
#include <QCoreApplication>
#include <QString>
#include <QTextStream>
#include <QDebug>
int main(int argc, char **argv)
{
QCoreApplication application(argc, argv);
QTimer timer;
QTextStream textStream(stdout);
QString word = "apple";
int i = 0;
QObject::connect(&timer, &QTimer::timeout, [&textStream, word, &i] () {
if (i < word.size()) {
textStream << word.at(i) << flush;
++i;
}
});
timer.start(1000);
return application.exec();
}
main.pro
TEMPLATE = app
TARGET = main
QT = core
CONFIG += c++11
SOURCES += main.cpp
Build and Run
qmake && make && ./main
Output
apple
This is happening, because you're blocking the thread. In most cases you're interested in using event loop.
You can use timer and increment a counter in a slot function. Every QObject has support for timer. You can start it using int QObject::startTimer(int interval) and it will call virtual void timerEvent(QTimerEvent *event) every interval miliseconds (it's a virtual method - reimplement it).
You can also use QTimer and connect QTimer::timeout() signal to accomplish the same thing.
Inside timer handler increment a counter and print the character.
It's a good idea to put your hands on finite state machine concept. FSMs are a great tool for solving similar problems problems. In fact, using a timer callback you create a state machine, but very simple one.
I still don't know what the problem is, but I found a make-shift solution. In my program I include one class (eg class1) into my mainwindow.cpp and from that class I include the timer class. I solved the problem by removing the timer class and adding all those functions to class1. Doesn't make sense to me, but it works.
Related
I use synchronously block QThread::sleep() function to do timing, which shows number one after another by the time.
the expected running process is synchronously block current thread 2 seconds, and run the following code to change displayed number, and synchronously block another 2 seconds, and so on..., the thought works well in non GUI program.
but in GUI mode, the label only show 9, which is the last number to be displayed.
what leads to the different outcome of the synchronous blocking function sleep in GUI and non GUI program?
#include <windows.h>
#include "widget.h"
#include "ui_widget.h"
#include <QDebug>
#include <QThread>
Widget::Widget(QWidget *parent) :
QWidget(parent),
ui(new Ui::Widget)
{
ui->setupUi(this);
}
Widget::~Widget()
{
delete ui;
}
//slot of start timing button
void Widget::on_pushButton_2_clicked()
{
for(int i=0;i<10;i++){
QThread.sleep(2);
ui->label->setText(QString::number(i));
}
}
The GUI needs to continually verify events such as the mouse, the keyboard, etc. and perform actions if certain conditions are met, that is called eventloop. In the case of sleep() it is a blocking task that does not allow the eventloop to run, generating the GUI to freeze (if you want to verify it, try to change the size of the window), so inside the GUI thread you should avoid to use that kind of functions, the blocking tasks you have to turn them into asynchronous or execute it in another thread.
But the task of the sleep() can be replaced by a QTimer without blocking the GUI:
*.h
#ifndef WIDGET_H
#define WIDGET_H
#include <QTimer>
#include <QWidget>
namespace Ui {
class Widget;
}
class Widget : public QWidget
{
Q_OBJECT
public:
explicit Widget(QWidget *parent = 0);
~Widget();
private slots:
void on_pushButton_2_clicked();
void onTimeout();
private:
Ui::Widget *ui;
int counter;
QTimer timer;
};
#endif // WIDGET_H
*.cpp
#include "widget.h"
#include "ui_widget.h"
#include <QLabel>
Widget::Widget(QWidget *parent) :
QWidget(parent),
ui(new Ui::Widget)
{
ui->setupUi(this);
counter = 0;
connect(&timer, &QTimer::timeout, this, &Widget::onTimeout);
}
Widget::~Widget()
{
delete ui;
}
void Widget::on_pushButton_2_clicked()
{
timer.start(2000);
}
void Widget::onTimeout()
{
ui->label->setText(QString::number(counter));
counter++;
if(counter > 10){
counter = 0;
timer.stop();
}
}
Another option is to use QEventLoop with QTimer:
void Widget::on_pushButton_2_clicked()
{
for(int i=0;i<10;i++){
QEventLoop loop;
QTimer::singleShot(2000, &loop, &QEventLoop::quit);
loop.exec();
ui->label->setText(QString::number(i));
}
}
Update:
what leads to the different outcome of the synchronous blocking function sleep in GUI and non GUI program?
If you are creating a non GUI application using Qt you will also have problems, although the effect may be less visible.
In the case of the GUI as I said there is an eventloop that handles events, and among them that of repainting, I mean when you set the new text in the QLabel, this is not painted automatically but Qt decides the right moment. That's why when you use QThread::sleep() you do not have time to update the painting.
Obviously in a non GUI application, the eventloop does not verify many events as the one painted by it does not see the effect, in fact in a script that only prints numbers it does not verify any event.
To notice the problem, let's use the following example:
#include <QCoreApplication>
#include <QThread>
#include <QTimer>
#include <QDebug>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QTimer timer;
QObject::connect(&timer, &QTimer::timeout, [](){
qDebug()<< "hello world";
});
timer.start(1000);
qDebug()<< "start blocking";
QThread::sleep(10);
qDebug()<< "end blocking";
return a.exec();
}
We will see that nothing is printed until the sleep() ends, that is, blocking the eventloop that allows the QTimer to do its work.
Answering your comment:
but what still makes me puzzled is why after finishing executing sleep function, after stopping blocking current thread, the following codes can't run as normal
ui->label->setText(QString::number(i)); this statement, right after sleep function
Asynchronous tasks such as painting have less priority than synchronous tasks, that is to say first Qt will execute the for loop and then just do the asynchronous tasks, so in the for the variable that stores the QLabel text is updated, that is to say 0, 1 , ..., 9, and after that, the task is handed over to the eventloop so that it just paints the last value, that is, the 9.
Note:
You can force the evenloop to update within synchronous execution with QXXXApplication::processEvents(), but this is often considered a bad practice, I only show it so you know it but avoid using it:
for(int i=0;i<10;i++){
QThread.sleep(2);
ui->label->setText(QString::number(i));
QApplication::processEvents();
}
I know my question is similar to this QUESTION but i cant find solution from there. Can anyone give a breif answer to my problem?
I have a function like this
void myWidget::showGPS()
{
/* This function will read data from text file
that will continuouly change over time
then process its data */
}
I want to call this function every 15-20 seconds without using Quick-and-dirty method of setting boolean to true .
Is there any way to implement this using
QT signal and slot with timer or something like that
The method showGPS(), should be made a slot of MyWidget class.
Then on, its just a matter of using the QTimer class.
QTimer *timer = new QTimer(this);
connect(timer, SIGNAL(timeout()), myWidget, SLOT(showGPS()));
timer->start(15000); //time specified in ms
The above code will call showGPS(), every 15 seconds.
Since the call is periodic, you don't have to set the timer in one shot mode using the setSingleShot() method.
Edit:
This is a simple poc, to help you understand it..
#include <QApplication>
#include <QtGui>
#include <qobject.h>
class MyWidget : public QWidget
{
Q_OBJECT
public:
MyWidget()
{
timer = new QTimer(this);
QObject::connect(timer, SIGNAL(timeout()), this, SLOT(showGPS()));
timer->start(1000); //time specified in ms
}
public slots:
void showGPS()
{
qDebug()<<Q_FUNC_INFO;
}
private:
QTimer *timer;
};
int main(int argc, char **args)
{
QApplication app(argc,args);
MyWidget myWidget;
return app.exec();
}
While you can use QTimer for checking file changes, in your case QFileWatcher might be better solution.
I mean if I have many different signals which are connected to the same slot. I saw this question but can't understand the link in the answer. Can you give me simple example?
I think you can use this method:
[protected] int QObject::​senderSignalIndex() const
From Qt documentation:
Returns the meta-method index of the signal that called the currently executing slot, which is a member of the class returned by sender(). If called outside of a slot activated by a signal, -1 is returned.
For signals with default parameters, this function will always return the index with all parameters, regardless of which was used with connect(). For example, the signal destroyed(QObject *obj = 0) will have two different indexes (with and without the parameter), but this function will always return the index with a parameter. This does not apply when overloading signals with different parameters.
Warning: This function violates the object-oriented principle of modularity. However, getting access to the signal index might be useful when many signals are connected to a single slot.
Warning: The return value of this function is not valid when the slot is called via a Qt::DirectConnection from a thread different from this object's thread. Do not use this function in this type of scenario.
This function was introduced in Qt 4.8.
Here is a small example that I created for you that demonstrates how it works:
#include <QTimer>
#include <QMetaObject>
#include <QMetaMethod>
#include <QCoreApplication>
#include <QDebug>
#include <QObject>
class Foo : public QObject
{
Q_OBJECT
public slots:
void mySlot() {
QMetaMethod metaMethod = sender()->metaObject()->method(senderSignalIndex());
qDebug() << metaMethod.name();
qDebug() << metaMethod.methodSignature();
qApp->quit();
}
};
#include "main.moc"
int main(int argc, char **argv)
{
QCoreApplication coreApplication(argc, argv);
QTimer timer;
Foo foo;
QObject::connect(&timer, &QTimer::timeout, &foo, &Foo::mySlot);
timer.setSingleShot(true);
timer.start(1000);
return coreApplication.exec();
}
main.pro
TEMPLATE = app
TARGET = main
QT = core
CONFIG += c++11
SOURCES += main.cpp
Build and Run
qmake && make && ./main
Output
"timeout"
"timeout()"
In the following function, manager will emit finished(QNetworkReply*) signal, then the slot function getCategories(QNetworkReply*) will be called.
void getCategories()
{
connect(manager, SIGNAL(finished(QNetworkReply*)), this, SLOT(getCategories(QNetworkReply*)));
for(int i = 0; i < stores.size(); ++i)
{
request.setUrl(QUrl(QString("http://www.example.com/%1").arg(stores[i].store_id)));
manager.get(request);
}
}
If the second signal emitted when the first call of the slot function, does Qt start another thread to run the slot function as the response to the second signal? And if it is so, is there some method to let the second call of slot function wait until the first call is finished?
UPDATE:
I mean is there a possibility that the slot function run in the same time?
Unless you create them explicitly, there's no "visible" multi-threading in a Qt program. That means, Qt might use threads internally for e.g. network I/O, but that multithreading is shielded from you and you don't have to care about it. None of your code will be called from other threads, nor will your data be shared with other threads by means that would require you to care about synchronization.
Signal/slot connections come it two main flavors: direct and queued connections:
Direct connections are just function calls that are executed synchronously, with some extra function calls and lookup tables in between. If you emit a signal, all slots are called immediately, before the "emit signal();" returns (as Laszlo's example demonstrates).
Queued connections on the other hand are also executed on the main thread, without any parallelism/multi-threading. However, the slot calls are enqueued in the event loop's event queue: The method doing the emit is completed first, the control returns to the event loop, which then at some later point in time calls the slot(s). The slots are called one after another - the order of execution might not be defined, but they will never be called in parallel.
Now QNetworkAccessManager (QNAM) also works event-driven (*), with queued events: You call get(), the control returns to the event loop; the QNAM sends the request; later, after performing the network I/O, the response is received by QNAM. Think of the network I/O and completion of the response as events, like e.g. mouse clicks: The event occurs, it is put into the event queue, later the event loop calls some internal slot in QNAM, which then triggers finished() to be emitted and mySlot() to be called.
(*) In fact, depending on the platform, QNAM might indeed use multithreading. But that's an implementation detail hidden from the user - so one can stick to the "event-driven" mental model.
It does not start it in a second thread. AFAIK, it will be either a direct call or queued for handling by default. The situation also depends on how you are managing your threads.
There are several connection types you can choose from, but usually, the default (direct or queued) should be fine.
I will show you two examples to demonstrate that it also depends on what exactly emits the signal.
Case 1 (Emitted by the slot being executed)
main.cpp
#include <QObject>
#include <QThread>
#include <QDebug>
#include <QCoreApplication>
class MyClass : public QObject
{
Q_OBJECT
public:
explicit MyClass(QObject *parent = 0) : QObject(parent), counter(0)
{
connect(this, SIGNAL(mySignal()),
this, SLOT(mySlot()), Qt::QueuedConnection);
}
signals:
void mySignal();
public slots:
void mySlot()
{
if (counter >= 2) return;
++counter;
qDebug() << "mySlot started";
emit mySignal();
QThread::msleep(1000);
qDebug() << "mySlot quit";
}
private:
int counter;
};
#include "main.moc"
int main(int argc, char **argv)
{
QCoreApplication application(argc, argv);
MyClass myObject;
myObject.mySlot();
return application.exec();
}
main.pro
TEMPLATE = app
TARGET = test
QT = core
SOURCES += main.cpp
Build and Run
moc -o main.moc main.cpp && qmake && make && ./test
Output
mySlot started
mySlot quit
mySlot started
mySlot quit
You would get the following output without queued connection to indicate that it would be a direct call in the middle of the slot execution in my example:
mySlot started
mySlot started
mySlot quit
mySlot quit
Case 2 (not emitted by the slot being executed)
main.cpp
#include <QObject>
#include <QThread>
#include <QDebug>
#include <QCoreApplication>
#include <QTimer>
class MyClass : public QObject
{
Q_OBJECT
public:
explicit MyClass(QObject *parent = 0) : QObject(parent), counter(0), timer(new QTimer(this))
{
// Note: there is no need for queued connection in this case
connect(this, SIGNAL(mySignal()), this, SLOT(mySlot()));
connect(timer, SIGNAL(timeout()), this, SLOT(mySlot()));
timer->setSingleShot(true);
timer->start(200);
}
signals:
void mySignal();
public slots:
void mySlot()
{
++counter;
qDebug() << "mySlot started" << counter;
QThread::msleep(1000);
qDebug() << "mySlot quit" << counter;
}
private:
int counter;
QTimer *timer;
};
#include "main.moc"
int main(int argc, char **argv)
{
QCoreApplication application(argc, argv);
MyClass myObject;
myObject.mySlot();
return application.exec();
}
main.pro
TEMPLATE = app
TARGET = test
QT = core
SOURCES += main.cpp
Build and Run
moc -o main.moc main.cpp && qmake && make && ./test
Output
mySlot started 1
mySlot quit 1
mySlot started 2
mySlot quit 2
I'm new to StackOverflow and wondering if I'm doing this right:
I'm writing a simple Qt application to test multi-threading (something I am also completely new to). I made a MainWindow that contains widgets, and a class MyThread that subclasses QThread and overrides the run() method.
The application simply displays two buttons, "Start Counter" and "Stop Counter", and a text field. When "start counter" is pressed, a worker thread is created and runs in the background, continuously incrementing a counter in a while loop and signaling the main thread (where the GUI is) with the updated value. When "Stop Counter" is pressed, a signal is sent to the main thread that stops the while loop, and the counter is stopped until "Start Counter" is pressed again.
This works perfectly fine ... but is it the best way? I'm new at this, and read a lot of people saying "don't subclass QThread" and other people saying "subclass QThread", and it's a little bit confusing. If this isn't the best way to implement this sort of thing (run a computationally-intensive loop in a background thread with "start" and "stop" buttons), what is? If I'm doing it wrong, how do I do it right? I don't want to learn the wrong way.
Thank you! And here's the code:
MyThread.h
#ifndef MYTHREAD_H
#define MYTHREAD_H
#include <QThread>
#include <QMutex>
class MyThread : public QThread
{
Q_OBJECT
public slots:
void stopRunning();
protected:
virtual void run();
signals:
void signalValueUpdated(QString);
private:
bool isRunning;
};
MyThread.cpp
#include "MyThread.h"
#include <QString>
void MyThread::run()
{
qDebug("Thread id inside run %d",(int)QThread::currentThreadId());
static int value=0; //If this is not static, then it is reset to 0 every time this function is called.
isRunning = 1;
while(isRunning == 1)
{
QString string = QString("value: %1").arg(value++);
sleep(1/1000); //If this isn't here, the counter increments way too fast and dies, or something; the app freezes, anyway.
emit signalValueUpdated(string);
}
}
void MyThread::stopRunning()
{
isRunning = 0;
}
MainWindow.h
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QApplication>
#include <QPushButton>
#include <QHBoxLayout>
#include <QLineEdit>
#include "MyThread.h"
class MainWindow : public QWidget
{
Q_OBJECT
public:
MainWindow(QWidget *parent = 0);
private:
//Widgets
QHBoxLayout * boxLayout;
QPushButton * startButton;
QPushButton * stopButton;
QLineEdit * lineEdit;
MyThread thread;
};
#endif
MainWindow.cpp
#include "MainWindow.h"
MainWindow::MainWindow(QWidget *parent) : QWidget(parent)
{
boxLayout = new QHBoxLayout(this);
startButton = new QPushButton("Start Counter", this);
stopButton = new QPushButton("Stop Counter", this);
lineEdit = new QLineEdit(this);
boxLayout->addWidget(startButton);
boxLayout->addWidget(stopButton);
boxLayout->addWidget(lineEdit);
qDebug("Thread id %d",(int)QThread::currentThreadId());
//When the start button is pressed, invoke the start() method in the counter thread
QObject::connect(startButton,SIGNAL(clicked()),&thread,SLOT(start()), Qt::QueuedConnection);
//When the stop button is pressed, invoke the stop() method in the counter thread
QObject::connect(stopButton,SIGNAL(clicked()),&thread,SLOT(stopRunning()), Qt::QueuedConnection);
//When the counter thread emits a signal saying its value has been updated, reflect that change in the lineEdit field.
QObject::connect(&thread,SIGNAL(signalValueUpdated(const QString&)),lineEdit,SLOT(setText(const QString&)), Qt::QueuedConnection);
}
Most of the time QThread sub-classing is a wrong way to do threading in Qt. I suggest you to read an article about threads, event loops and other which could give you an idea how to use threads in Qt in a better way. But do not listen to anyone who arguing that there is the only one right way to use QThread. There are 2 ways and while subclassing is not needed in general it could be useful sometimes. You just need to use non-subclassing way until you really need to subclass. In your particular case you don't need subclassing.
Replace sleep(1/1000); with msleep(100); Things will be just fine :)