[Interest] Widget event called after it has been deleted

[Etienne Sandré-Chardonnal]

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 <andre at 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!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130919/733f4213/attachment.html>