[Interest] Widget event called after it has been deleted
André Somers
andre at familiesomers.nl
Thu Sep 19 10:23:16 CEST 2013
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!
More information about the Interest
mailing list