Actually, I almost always use deleteLater() for widgets, that's much safer regarding this issue, and there is no drawback. Here I was trapped because delete was hidden inside QScrollArea::setWidget(). Fortunately I could use QScrollArea::takeWidget()->deleteLater()
I really think that replacing delete by deleteLater() in QScrollArea::setWidget() will improve safety and may cause no harm. Etienne 2013/9/19 André Somers <an...@familiesomers.nl> > 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