QT + Cómo llamar a la ranura desde el código personalizado de C++ que se ejecuta en una secuencia diferente

Question

Soy nuevo en QT y estoy aprendiendo algo.

Me gustaría activar una ranura que modifique un widget GUI a partir de un hilo C++ (actualmente un Qthread).

Desafortunadamente consigo una: Error de aserción en: Q_ASSERT (QAPP & & qApp-> hilo() == QThread :: currentThread());

Aquí hay un código:

(clase hilo principal +)

class mythread : public QThread 
    { 
    public: 
     mythread(mywindow* win){this->w = win;}; 
     mywindow* w; 
     void run() 
     { 
      w->ui.textEdit->append("Hello");  //<--ASSERT FAIL 
      //I have also try to call a slots within mywindow which also fail. 
     }; 
    }; 

    int main(int argc, char *argv[]) 
    { 
     QApplication* a = new QApplication(argc, argv); 
     mywindow* w = new mywindow(); 

     w->show(); 
     mythread* thr = new mythread(w); 
     thr->start(); 

     return a->exec(); 
    } 

Ventana:

class mywindow : public QMainWindow 
{ 
    Q_OBJECT 

public: 
    mywindow (QWidget *parent = 0, Qt::WFlags flags = 0); 
    ~mywindow(); 
    Ui::mywindow ui; 

private: 



public slots: 
    void newLog(QString &log); 
}; 

Así que tengo curiosidad sobre cómo actualizar la parte GUI de código en una hilo diferente.

Gracias por ayudar

Answer 1

Además de stribika's answer, a menudo resulta más fácil de usar una conexión de señal/ranura. Puede especificar que debe ser una conexión en cola cuando la conecta, para evitar problemas con las señales del hilo en el contexto de su objeto propietario.

class mythread : public QThread 
{ 
signals: 
    void appendText(QString); 
public: 

    mythread(mywindow* win){this->w = win;}; 
    mywindow* w; 
    void run() 
    { 
     emit (appendText("Hello")); 
    }; 
}; 

int main(int argc, char *argv[]) 
{ 
    QApplication* a = new QApplication(argc, argv); 
    mywindow* w = new mywindow(); 

    w->show(); 
    mythread* thr = new mythread(w); 
    (void)connect(thr, SIGNAL(appendText(QString)), 
        w->ui.textEdit, SLOT(append(QString)), 
        Qt::QueuedConnection); // <-- This option is important! 
    thr->start(); 

    return a->exec(); 
} 

Answer 2

Es necesario utilizar QMetaObject::invokeMethod. Por ejemplo:

void MyThread::run() { 
    QMetaObject::invokeMethod(label, SLOT(setText(const QString &)), Q_ARG(QString, "Hello")); 
} 

(El código anterior proviene de aquí: http://www.qtforum.org/article/26801/qt4-threads-and-widgets.html)

Answer 3

no creo que se les permite llamar directamente a las cosas que se traduce en eventos de pintura de cualquier otro hilos que el hilo principal. Eso dará lugar a un bloqueo.

Creo que puede usar el bucle de eventos para llamar a las cosas de forma asincrónica, de modo que el hilo de la interfaz principal se recupere y luego realice la actualización desde el hilo principal, que es lo que sugiere cjhuitt.

Answer 4

stribika consiguieron casi a la derecha: la derecha

QMetaObject::invokeMethod(textEdit, "append", Qt::QueuedConnection, 
          Q_ARG(QString, myString)); 

de cjhuitt, sin embargo: Por lo general, desea declarar una señal en la rosca y conectarlo a la ranura append(), para conseguir la gestión de objetos de por vida gratis (bueno, por el precio de un cambio de interfaz menor). En una nota, el argumento adicional:

   Qt::QueuedConnection); // <-- This option is important! 

de la respuesta de cjhuitt ya no es necesario (que era, en Qt < = 4,1), ya que connect() defecto Qt::AutoConnection que ahora (Qt> = 4.2) hace la derecha y cambia entre el modo de conexión en cola y directo basado en QThread::currentThread() y la afinidad de subprocesos del receptor QObject en emiten hora (en lugar de afinidad entre el emisor y el receptor en el momento de la conexión).

Answer 5

¿Qué pasa si nuestra afinidad por el hilo dice GUI, pero no estamos en el hilo de GUI, ni en un QThread?

Lo que quiero decir es que un subproceso no de Qt (notificación) llama al método de interfaz de QObject, en el que se emite una señal de Autoconexión.La afinidad de Subproceso del QObject es el subproceso Principal, pero el procedimiento se llama realmente desde otro subproceso. ¿Qué hará el Qt aquí?