That's a great hint! Thank you! =)
On Mon, Feb 9, 2015 at 5:27 PM, Thiago Macieira
wrote:
> On Monday 09 February 2015 17:23:53 Valery Kotov wrote:
> > It could be an option. But, the problem here, I have no clue where to
> put a
> > breakpoint. =) I would expect it should be somewhere around QM
On Monday 09 February 2015 17:23:53 Valery Kotov wrote:
> It could be an option. But, the problem here, I have no clue where to put a
> breakpoint. =) I would expect it should be somewhere around QMetaObject. I
> will dig deer to find out.
All signal activations are a call to QMetaObject::activate
Hello Thiago,
Thank you for your hints!
> Why is it queued? You're adding a delay of one full event loop processing
> after the timer fires, which already happens inside the event loop.
Actually, it is direct. My bad. I didn't notice that it uses auto.
> You can do that if you write a testcase.
On Thursday 05 February 2015 16:22:40 Valery Kotov wrote:
> Greetings everybody!
>
> I'm looking for a piece of advice. Let me describe the problem. We have
> QTimer which emits a signal each N seconds. The timer has queued connection
> between "timeout" signal and sltTimeout slot. The slot has so
Greetings everybody!
I'm looking for a piece of advice. Let me describe the problem. We have
QTimer which emits a signal each N seconds. The timer has queued connection
between "timeout" signal and sltTimeout slot. The slot has some output (to
identify if the signal was emitted).
For some time we
