[Qt-qml] reparent on destruction

[Artem Marchenko]

Hi Pekka

If I read the documentation correctly it is the order of onDestruction handlers that is undefined. To my understanding all the onDestruction handlers are called before the actual destruction happens so unless your item or its children/parent don't kill something important from their onDestruction, you should be safe to reparent from this handler.

If I am wrong, then you'll probably have to care about reparenting by manually reparenting before the view is destroyed. That is if you know who kills it from where.

Best regards,
Artem.

On Sep 20, 2011, at 8:44 AM, <Pekka.E.Jokela at nokia.com> <Pekka.E.Jokela at nokia.com> wrote:

> Hi,
> Is there a way to re-parent a child item on the destruction?
>  
> I would like to re-use a QML item in several views, because the item consumes a lot of memory and takes time to initialize. When a view becomes active, the item is re-parented to that view. This way, the  transformations and z-order of the re-cycled item matches the view. Now the problem arises when the active view is destroyed at run-time. We would need to re-parent the recycled item to the next visible view on the view stack. How this can be done?
>  
> View {
>     Component.onDestruction {
>        recycledChild.parent = newView
>     }
> }
>  
> Problem with this approach is that the recycledChild is, at the time of the deletion, a child of the deleted view and the destruction order is undefined i.e. the child items are most likely destroyed already.
>  
> One option is implement the View in c++ and re-parent in the destructor, but then we cannot “derive” from QML items like Page element from qt-components.
>  
> -Pekka
>  
>  
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-qml

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20110926/dd9ac5e6/attachment.html