Nominate our 2022 Qt Champions!

Modifying Window After exec()?

  • Hi there! I'm relatively new to Qt, and I've stumbled on to a bit of a conundrum. Basically, the regular Qt GUI program does:

    QApplication a(argc, argv);
    MainWindow w;;
    return a.exec();

    Here's the problem the a.exec() seems to handle all the functions for updating the Window and dealing with all that nonsense that me as the programmer wouldn't want to deal with because Qt handles it.

    The problem is this blocks execution of anything else after it, and the solution to that would be threads. I tried using normal threads but as soon as I try to modify any data, I get a crash. So the only thing I could think of is that QThreads must be something that can deal with this or what have you.

    Basically I want just what I get from a basic Qt application, but I also want to set up my own loop that handles other things like adding to a list for example.

    Does anybody have an example application of this in action? It would be hugely helpful.

  • Lifetime Qt Champion

    Hi and welcome to devnet,

    One way of doing such a thing is described in the Mandlebrot example

    Hope it helps

  • I saw that, however it doesn't completely accomplish what it is I'm looking for. That inherits QThread and kind of forces me to do my stuff in a separate thread. Is there any way for me to have the application run in a separate thread so it doesn't block the main thread, but still allows me to send information to the Window?

  • @Spirrwell I think you're looking (completely) in the wrong direction. The exec() doesn't 'block' anything, it just happens to block in the scope of the main function, however, internally it is continuously executing events that appear on the message loop - the key word being 'event-driven'.

    In other words: you can easily change anything you want, as a result of any event, for instance a keyboard or mouse event. Simply write a slot or event handler that is executed as a result of such an event in order to change anything you want in the window.

    Separate threads are meant for long-lasting calculations (like the Mendelbrot example) that would otherwise block the main-thread, hence block the UI while the calculation is going on.

  • @Spirrwell As to your specific question to run the application in a different thread: no, absolutely impossible, and for extremely good reasons.

  • Lifetime Qt Champion

    @Jakob In fact it's possible, it requires particular handling but it's doable. In this case I wouldn't recommend it at all though.

  • Lifetime Qt Champion

    @Spirrwell said:

    The problem is this blocks execution of anything else after it (exec)

    Hi, normally that is not a issue. You would have most of the code in
    Main window and use signal and slot to handle talking to different parts/objects of the program.
    Unlike traditional windows programming, you do not define your own message loop in qt.
    You use signals and slots
    If you want something to run from time to time to do light stuff, a QTimer can also be used.
    Ofcause QThread is also an option but its for long lasting calculations and or designs where you need a
    asynchronous data handler.

  • Thank you. I finally got QThread to do what I'm trying to accomplish, however, it is a bit of a pain. As I'm trying to create an interface for a game engine that I've been working on for learning purposes. But, it's getting the job done and with some #ifdefs I think I can make it work.

    I connected slots and whatnot in the main()

    #include "mainwindow.h"
    #include <QApplication>

    MainWindow *w;

    int main(int argc, char *argv[])
    QApplication a(argc, argv);

    w = new MainWindow();
    Engine t;
    QObject::connect(&t, SIGNAL(addToObjectList(QString)), w, SLOT(addObjectToList(QString)));
    QObject::connect(w,SIGNAL(destroyed(QObject*)), &t, SLOT(Terminate()));
    int r = a.exec();
    delete w;


    return r;


Log in to reply