Important: Please read the Qt Code of Conduct -

Signal/slot and update gui

  • I try to describe briefly what I have :

    Thread1 receives data via the network and sends signals according to the content.
    The main thread (with the gui), has a slot that is connected to thread1's signal. As data sometimes arrives fast, it may happen that several signals are sent consecutively with a very small interval (let's say 5 signals can be sent before the slot has handled the first). So, a number of signals get probably queued.
    From the slot, other functions are called that update widgets on the screen.

    I would expect that the screen gets updated after each execution of the slot. However, I notice that the screen only gets updated after all (queued?) signals are handled by the slot.
    I suppose this is normal behaviour ? Is there a way to make the screen update after each execution of the slot ? I thought, at the end of the slot, execution returns to the main event loop and the gui has the possibility to update itself. Obviously, this is not the way it works...

    I tried to explicitly add Qt::QueuedConnection where signal and slot get connected, but that didn't change the behaviour (I think, by default it already was a QueuedConnection because signal and slot are in different threads).

    Other question : is there a way to check the number of signals on the 'queue' (or the number of unhandled signals) ?

  • I added a repaint() call at the end of the slot function. This seems to work. The screen gets updated faster now (i.e. after the first execution of the slot).
    Nevertheless, I have the feeling that this is probably not good practice... Are there other, better solutions ?

Log in to reply