Hi, On Sunday 07 August 2016 10:06:54 Thiago Macieira wrote: > On domingo, 7 de agosto de 2016 10:17:44 PDT André Somers wrote: > > > Yet, I don't see where the problem is. QDialog::exec() displays a > > > modal > > > dialog. It is not possible to click again on the menu or button that > > > displayed the dialog in the first place. It effectively breaks > > > recursive > > > looping, right? > > > > Wrong. There are many sources of events, and only the ones related to > > user input are blocked this way. > > Indeed. Think of your sockets, that are still receiving data and that is > being processed. Are you sure that your dialog wasn't created as a > response to some data being processed earlier? > > Think also of all the timers that will time out.
Let me weigh in at this point: yes, it is true - nested event loops make it
very easy to shoot yourself in the foot. Sorry, you are using C++, if you
wanted it safe you would bake bread.
I use them all the time because they make simple algorithms understandable -
event based constructs, even using lambdas, make them horribly hard to
understand. I even wrote a few such methods for my own code.
Here's the choice:
a) avoid exec() at all costs and suffer unreadable code and a lot of the
problems described below simply get hidden in a forest of less readable code
b) follow a few simple rules instead:
- avoid direct delete on QObjects - use deleteLater instead (it is delayed
for the main event loop)
- use high-level methods instead of deletes: e.g. tell a window to close
itself and set it up for automatic cleanup instead of deleting it directly
- try to communicate via signals and set the connections up when you create
the receiver object - Qt will clean the connections up when the receiver is
deleted
- if you absolutely and positively cannot avoid using a pointer - use
QPointer and check it before you call a method
- enable your code to deal with disappearing objects - i.e. let a child
object tell its parent that it is gone and stop any actions that depend on
it when you receive this signal (otherwise you risk endless waiting)
- when you write code that can take a while: think about everything that
could conceivably happen in between and prepare the program for "stuff
happening" - i.e. disappearing objects, more events coming in, things
queuing up, the user losing patience and clicking "Exit", etc.
Qt make it very easy for you to write readable code - I refuse to compromise
this out of paranoia.
Konrad
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
