A communication instance between Qt multithreading Emit__emit

Problem Description: The interface thread Mainapp is the primary thread, the worker thread is mythread as a child thread, and the position is passed from the worker thread to the main thread to change the pushbutton position of the button in the main thread.

Note: The signal and slot mechanism of QT can bind any object inheriting from the Qobject class so that different objects can communicate with each other.

Here are several implementations of the file

Mythread.h

#ifndef Mythread_h

#define Mythread_h

#include <QThread>

#include <QPushButton>

Class Mythread:public Qthread

{

    Q_object

Public

    Explicit Mythread (Qpushbutton *PB);

    ~mythread ();

    Qpushbutton *PB;

Signals:

    void change_postion (int); A signal function used to send data to the main thread, in. cpp, not defined, directly using emit to send data

Protected

    void run ();

Public Slots:

Private

};

#endif//Mythread_h

Mythread.cpp

#include "Mythread.h"

#include <QDebug>

Mythread::mythread (Qpushbutton *PB):

    Qthread ()

{

    THIS->PB = PB;

}

void Mythread::run ()

{

    int i = 0;

    while (true)

    {

        Qdebug ("The number is:%d", i);

        i + 10;

        Emit change_postion (i); The communication between multithreading sends the value of I to the main thread

        This->msleep (1000);

        if (i = = 400)

        {

            i = 0;

        }

    }

}

Mythread::~mythread ()

{

}

MainWindow.h

#ifndef Mainwindow_h

#define Mainwindow_h

#include <QtGui/QMainWindow>

#include "Mythread.h"

Class Mainwindow:public Qmainwindow

{

    Q_object

Public

    MainWindow (Qwidget *parent = 0);

    ~mainwindow ();

    Mythread *thread;

    Qpushbutton *PB;

Private Slots:

    void Move_button (int i);

};

#endif//Mainwindow_h

MainWindow.cpp

#include "Mainwindow.h"

#include <QDebug>

Mainwindow::mainwindow (Qwidget *parent)

    : Qmainwindow (parent)

{    

    This->setgeometry (0, 0, 400, 400);

    PB = new Qpushbutton ("AA", this);

    thread = new Mythread (PB);

    To connect the signal in the child thread with the reaction slot function of the main path

    Connect (thread, SIGNAL (change_postion (int)), this, SLOT (Move_button (int)), qt::queuedconnection); The overload of the Connect function, the last parameter needs to be noted, cannot use the default

    Thread->start ();

}

Mainwindow::~mainwindow ()

{

    Delete thread;

}

void Mainwindow::move_button (int i)

{

    Pb->move (i, I);

}

Main.cpp

#include <QtGui/QApplication>

#include "Mainwindow.h"

int main (int argc, char *argv[])

{

    Qapplication A (argc, argv);

    MainWindow W;

    W.show ();

    return A.exec ();

}

Problems encountered during implementation:

The fifth parameter of the 1.connect function represents the connection mode of the signal to the slot, and the signal and slot between the threads cannot use QT::D irectconnection direct connection, because it requires that the slot function be executed within the signaled thread. The Qt::queuedconnection queue method converts the signal into a message queue in which the slot function is sent to the thread, so that the slot functions can be processed in a threads thread-safe communication between threads. Such timeliness is also not bad, the above implementation, will be in the child thread "run ()" function in the second sleep before the main thread of the "change_position(int)."

So at the time of debugging the child thread's "emit change_position (int);" The next step does not immediately jump to the main thread of "Move_button(int)", I began to think that the signal was lost halfway to the service. and forcing the use of QT::D irectconnection mode can not get rid of mistakes.

2. Use "Signal and slot" to pass reference parameters between threads, be sure to add a const, because the const literal constant exists in the constant area and the lifecycle is as long as the program. This avoids the slot of the arguments when the call is run over and invalidates the reference.

I didn't notice the need for a const, the program ran without reporting an error, but the main thread had no sign of using the string passed by the child thread, which made me even more mistaken to think that the child thread was sending a signal that it was missing.