Op 18-9-2013 11:53, Etienne Sandré-Chardonnal schreef: > Dear all, > > In my app, I have two main widgets : > - One displaying a tree (TreeWidget) and allowing selecting nodes. > - One for editing the selected node (EditWidget), embedded in a > QScrollArea > > Selecting a node sets a new EditWidget using QScrollArea::setWidget. > This deletes the previous widget with a standard "delete" statement as > seen in Qt code. > > One of the possible actions in EditWidget tells the TreeWidget to > select another node. This is the issue : it crashes because a queued > event (generally a focus out) gets called while the widget is deleted > already. > > 1) I know could use a QueuedConnection for the previously described > action, but I don't like that kind of GUI design where a > QueuedConnection is required to avoid an app crash... > > 2) I could use scrollArea->takeWidget()->deleteLater() before > setWidget(). I will try that. > > 3) Wouldn't it be better to use deleteLater() in the > QScrollArea::setWidget ? This would solve the issue here. How about > changing this in Qt source? > > I'm using 4.8.1 > > Etienne > Basically, you should not, directly or indirectly, delete the caller of a signal as a result of the emitting of that signal. That may be very hard to guarantee in the case of indirect calls. So conversely, you should be ready for *any* method to be called on the object emitting the signal, including the destructor. You found that out the hard way. I find the "Delta Object Rules" [1] to be an interesting read in this respect. I think Qt could really do with some methods to make this easier to deal with, but I don't think that changing to use deleteLater in this specific case will help in the general sense.
André [1] http://delta.affinix.com/dor/ -- You like Qt? I am looking for collegues to join me at i-Optics! _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
