| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Hi, I'm having a problem due to a timer firing at the "wrong" time. I think I have a solution but I know to little of the inner loops of Qt main loop for this. Can a read/write operation on a QTcpSocket or emitting another signal trigger a timer signal? As it's a one thread only application I understand that timers can only signal when the runtime is inside a Qt event loop such as main loop? -- [ signature omitted ]
Robin Helgelin wrote: > Hi, > > I'm having a problem due to a timer firing at the "wrong" time. I > think I have a solution but I know to little of the inner loops of Qt > main loop for this. > > Can a read/write operation on a QTcpSocket or emitting another signal > trigger a timer signal? As it's a one thread only application I > understand that timers can only signal when the runtime is inside a Qt > event loop such as main loop? > QTimer will dispatch an immediate signal, when it is updated and sees that at least the timeout time has passed since it was started. This update happens during the event loop. Thus, if you have a timer with a timeout time of 100 milliseconds, but a single run of the event loop takes a full second, then the timer will only be firing once per run of the event loop, (1/second instead of the desired 10/second) If you have a really long operation that you just cant get around, then you might consider putting the timer in it's own thread, (which gets its own event loop) and then handling the communication between threads to signal the timeout. Hope this helps! -Rob -- [ signature omitted ]
On Feb 4, 2008 8:02 PM, Rob Douglas <rwdougla@xxxxxxxxx> wrote: > QTimer will dispatch an immediate signal, when it is updated and sees > that at least the timeout time has passed since it was started. This > update happens during the event loop. Thus, if you have a timer with a > timeout time of 100 milliseconds, but a single run of the event loop > takes a full second, then the timer will only be firing once per run of > the event loop, (1/second instead of the desired 10/second) > > If you have a really long operation that you just cant get around, then > you might consider putting the timer in it's own thread, (which gets its > own event loop) and then handling the communication between threads to > signal the timeout. Well, the problem is really the opposite, the timer signal is emitted as it should, I'm more interested what parts of my code that really goes as far as into the Qt mechanism and emits the signal when it really should stick around in my code. The only thing that leaves my code is a QTcpSocket-write and an emitted signal from my code, yet somehow, it seems the timer sometimes trickles through in between here. -- [ signature omitted ]
Robin Helgelin wrote: >The only thing that leaves my code is a QTcpSocket-write and an >emitted signal from my code, yet somehow, it seems the timer sometimes >trickles through in between here. QIODevice::write() and QTcpSocket don't cause the event loop to spin. Nor do the waitForReadyRead() or waitForBytesWritten() function. Can you provide more information? Are you using processEvents()? Or a modal dialog? -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Feb 4, 2008 9:51 PM, Thiago Macieira <thiago.macieira@xxxxxxxxxxxxx> wrote: > QIODevice::write() and QTcpSocket don't cause the event loop to spin. Nor > do the waitForReadyRead() or waitForBytesWritten() function. > > Can you provide more information? Are you using processEvents()? Or a > modal dialog? Actually yes, didn't take notice of that code yesterday. A modal dialog is closed with a call to accept(). Maybe that makes it down to event loop for redrawing windows? -- [ signature omitted ]
On Tuesday 05 February 2008 10:18:59 Robin Helgelin wrote: > On Feb 4, 2008 9:51 PM, Thiago Macieira <thiago.macieira@xxxxxxxxxxxxx> wrote: > > QIODevice::write() and QTcpSocket don't cause the event loop to spin. Nor > > do the waitForReadyRead() or waitForBytesWritten() function. > > > > Can you provide more information? Are you using processEvents()? Or a > > modal dialog? > > Actually yes, didn't take notice of that code yesterday. A modal > dialog is closed with a call to accept(). Maybe that makes it down to > event loop for redrawing windows? Yes, a modal dialog uses an event loop. That makes timers fire again, sockets be processed, etc. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Oops, forgot sending this to the list. On Feb 5, 2008 10:35 AM, Thiago Macieira <thiago.macieira@xxxxxxxxxxxxx> wrote: > Yes, a modal dialog uses an event loop. That makes timers fire again, sockets > be processed, etc. I know that, but as I'm currently in my code when this occurs it means I would need to get back to an event loop for the timer to fire again, and the only call that seems possible is QDialog::accept(), which spirals down to QWidget::setVisible(false). -- [ signature omitted ]
> I know that, but as I'm currently in my code when this occurs it means > I would need to get back to an event loop for the timer to fire again, > and the only call that seems possible is QDialog::accept(), which have a look at processEvents() http://doc.trolltech.com/4.3/qcoreapplication.html#processEvents Cheers, Peter -- [ signature omitted ]