Open jpcima opened 3 years ago
You have somewhere/something where this is happening right?
spectacle-analyzer in with-new-dpf
branch.
The UI keeps a vector fSubWidgets
which auto-deletes the elements.
(note that deletion order of vector is undefined)
remark: this would never be a problem is dgl took care of widget ownerships by itself
can you be more clear on your latest point? I thought this was already the case, when the subwidget is created and deleted it removes itself from the parent. doesnt a widget (top level or sub) delete its children on the destructor?
wouldnt this be solved by a simple fSubWidgets.clear()
on the (parent) widget destructor?
so it deletes the children before itself.
so it deletes the children before itself.
To elaborate, the problem is that it has 3 levels of widgets. example: UI →FloatingWindow → TextLabel. Delete FloatingWindow and then TextLabel, and it dies. This wouldn't happen in previous DPF.
doesnt a widget (top level or sub) delete its children on the destructor?
I'm pretty sure it doesn't, just clears the children array. (which are raw pointers)
ok but then the owning part makes sense. it doesnt make sense to have to delete the child windows manually. The UI should destroy child windows, and all the way down as well.
btw, comparing to old DPF is not very helpful, old DPF didn't do a couple of things right.
Using DPF 1d756d6 from develop, in the case of a parent subwidget which has other subwidgets as children, deleting the parent leaves the children having a dangling
parentWidget
pointer.The crash happens because of invalid access in
SubWidget::PrivateData
dtor.parentWidget->pData->subWidgets.remove(self);