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, <[email protected]> <[email protected]> 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 > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt-qml
_______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
