[Interest] Widget event called after it has been deleted

[Alex Malyushytskyy]

Does treeWidget use EditWidget anyhow after emitting signal explicitly in
you code?

I do not think returning to the caller after deleting unusded in the caller
object could  cause problem.
Problem may occur only  caller use outdated information about already
deleted object is used  after signal is emitted.
This may be caused by caller design (for example hashing of data ) or
already existing events in the queue.
You may try to process all the existing events before emitting signals.
If this does not help, this is mostly likely 1st case and I afraid it is
tough to discuss without testcase and debugging.

Alex



On Wed, Sep 18, 2013 at 2:54 PM, Etienne Sandré-Chardonnal <
etienne.sandre at m4x.org> wrote:

> 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/44a9a079/attachment.html>