Bug in WDialog::setId?
Added by Jason Ferrara over 5 years ago
It appears that if you do
mydialog = std::make_unqiue<Wt:WDialog>();
mydialog->setId("my_id");
...
mydialog->show()
and the in the finished handler
mydialog.reset();
you end with with random crashes. When the dialog is constructed, its zIndexChanged signal gets put in the applications exposedSignals_ list as .zIndexChanged, but when the dialog is deleted it tries to remove the signal as my_id.zIndexChanged, leading to an invalid entry left in exposedSignals_. Without the call to setId things work as expected. Is this a bug, or am I missing something from the documentation that says you shouldn't call setId on a WDialog?
Also, as an aside, the WDialog documentation recommends
mydialog = addChild(std::make_unique<WDialog>());
and then
mydialog->removeFromParent();
in the finish handler. But that leads to a memory leak during the lifetime of the parent widget, as WDialog::removeFromParent seems to always return an empty unique_ptr, leaving the dialog in the parent.
Replies (1)
RE: Bug in WDialog::setId? - Added by Roel Standaert over 5 years ago
You're right about that documentation, that should be removeChild(mydialog).
In general, I would strongly discourage the use of setId(...), because there can be nasty bugs caused by it. In general, you're supposed to only do it right after the widget was constructed and before it is added to the widget tree. A WDialog, because it is a global widget, is immediately and automatically added to the widget tree upon construction.
Is there a particular reason why you need to set the id? Usually, you can just use addStyleClass or setObjectName instead, depending on what you want to achieve.