[Interest] Strange problem where exec() of dialogs returns immediately

Nikos Chantziaras realnc at gmail.com
Sun Mar 11 19:12:05 CET 2012

On 11/03/12 19:58, Thiago Macieira wrote:
> On domingo, 11 de março de 2012 19.39.31, Nikos Chantziaras wrote:
>> The application is an engine for running
>> programs in it, and those programs have their own internal event loops.
>>    They call callbacks so the host application can advance its own event
>> loop.  In those callbacks I then do processEvents().  There's no way
>> around that.
> Yes, there is. You can use threads or you can use a custom event dispatcher.
> And this is assuming that you tried but was unable to integrate the loops by
> way of timer and socket notifier callbacks. Your choice should be:
> 1) if the library provides you with callbacks for when it updates timers and
> socket notifiers, use the standard Qt event loop
> 2) if the library does not provide that, but allows you to add sockets
> notifiers and timers, then you should write your own Qt event dispatcher
> (inheriting from QAbstractEventDispatcher) and register the Qt sources with
> that lib.
> 3) if the library does not provide either, you put its use in a thread
> Anything else is sub-optimal because you'll either wake up too often or you'll
> delay event processing. Or, more likely, both, which is worse.

It provides neither.  The callbacks are for doing graphics, audio and 
user input.  So threading is the only option.  I didn't go that route 
because you can't paint from a thread without using signals/slots, and 
that seemed rather inefficient compared to direct calls.

But I guess I'll give it a try anyway.  On modern hardware the overhead 
is probably not noticeable.

More information about the Interest mailing list