[Interest] QProgressDialog not showing & processEvents()

André Somers andre at familiesomers.nl
Mon Nov 18 10:36:39 CET 2013


Bo Thorsen schreef op 18-11-2013 9:27:
> Den 18-11-2013 08:59, Mandeep Sandhu skrev:
>>> You have two viable approaches here:
>>> * break up the saving method into chunks. That is, do a small part of the
>>> work of the saving, queue the next piece of work to be done, and return to
>>> the eventloop. The eventloop will then trigger the next queued piece of the
>>> work being done. This way, there is no need for processEvents() at all.
>>> * move your saving code to a worker object, and execute it in a separate
>>> thread. Also, no need to use processEvents, as the heavy lifting is done
>>> outside of the GUI thread.
>> I'd too suggest the separate thread method as it's more generic and
>> will across different scenario's.
>>
>> The only thing that you need to worry about is that your thread's
>> actions are in sync with what the GUI is showing. Eg: in case you
>> provide a cancel button, you'll have to inform the worker thread to
>> abort and wait for it to exit cleanly.
> I strongly object to using a thread for something this simple. Threading
> is to be avoided whenever possible, because it's so hard to debug. Use
> the chunks method instead.
To me, it really depends how easy splitting the work in chunks is going 
to be. Without knowing what is being saved, there is no way to know. 
Threading is indeed difficult to debug, but if used localized in the 
right way is also not *that* hard to manage. The big benefit is that the 
actual saving stays localized in a single simple function. Using the 
chunks method will spread it around. You'll end up with local variables, 
flags, etc. That might be easier, or it might be harder. It depends on 
the situation. That's why I mentioned both approaches in my reply.

We actually _do_ use threading for asynchronous I/O in our application, 
and that works rather nicely.

André




More information about the Interest mailing list