[Interest] Widget event called after it has been deleted

[Etienne Sandré-Chardonnal]

Nothing to do with threads. A QueuedConnection can be useful in a single
thread, because it defers the execution of the slot to the event loop,
instead of calling the slot directly from the signal code.

Let me explain the problem differently:
 - widget A emits a signal
 - widget B has a slot which effectively deletes A (because
QScrollArea::setWidget deletes its current widget)
 - I connected A's signal to B's slot (and this is meaningful in this GUI,
because A has a button that tells B to go to the parent, which replaces the
A widget for viewing current node's properties)

Just done like that, it crashes. Because after deleting A, B's slot returns
to A's meta-object signal code. Which is bad.

Using a QueuedConnection would solve the issue. Because execution of A's
signal would post an event for calling B's slot, then exit A's signal code,
return to event loop, and exectute B's slot. Then it's safe to delete A.
However, I do not like the stability of the program to rely on the type of
connection. That's not in the essence of modularity with signal/slots.

Thiago, if you read me, Could you confirm the above's statements?

Thanks,

Etienne







2013/9/18 Alex Malyushytskyy <alexmalvtk at gmail.com>

> >> 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...
>
> I do not see why you need to use QueuedConnection. I hope you do not want
> to say you have that 2 widgets you have are in different threads.
>
>
> On Wed, Sep 18, 2013 at 2:53 AM, Etienne Sandré-Chardonnal <
> etienne.sandre at m4x.org> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130918/77bdfadb/attachment.html>