Important: Please read the Qt Code of Conduct -

Problem with custom signals in threads

  • I need to do some heavy calculations, so I'm doing it in a thread to not cause the user interface to hang while it's still calculating. I used the methods described in the Mandelbrot example. I have a similar situation, an image has to be constructed, but I don't require it in a loop, so it's enough for me to do it in the thread's run()

    I have a custom signal in my thread class, like:


    void signal_ready(QImage image);


    I use

    @emit signal_ready(image);@

    at the end of the run() function.

    And I connect it with

    connect(&segThread, SIGNAL(signal_ready(QImage)),
    this, SLOT(slot_updateImage(QImage)) );

    in my MainWindow class.

    The problem is that I get a linker error that the signal_ready is an unresolved external symbol (Visual Studio 2005). Right, it does not have a function body, but even in the Mandelbrot example, there is only a declaration, no definition. What did I miss? If I use "signals: void signal_ready(QImage image){};" instead of "signals: void signal_ready(QImage image);" it builds and runs without error, but the slot_updateImage will never be called.

    Note: I use other signals and slots for buttons etc. and they all work fine. I have the moc file generation configured, and all my slots are generated and are there in the moc source file. However, my signal does not how up there. Should it?

    Another, not so critical question: is this the best way to do it? If the image is large enough, the redrawing will cost time. Wouldn't it be better to do the displaying (converting to a pixmap and assigning the pixmap to a label) in the thread as well? If I constantly redraw the image (for example, I have some brightness control, moving, etc.) it will lag on a slower computer. The obvious solution would be to give the thread control over my MainWindow class, like having a pointer parent->label1->setPixmap(...) but it doens't seem to elegant for me. I'm still new to Qt and curious if there is a better way to do this.

  • I think I found the problem: my thread class was in a separate source file, and I had to add a Q_Thread macro and MOC custom build step. Now it works :)

    My other question still stands: what is the most elegant solution to have not just the calculations, but the actual redrawing be done in a separate thread?

Log in to reply