Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QScrollArea::takeWidget() with the widget in a QGridLayout
I have a scroll area with a label as a placeholder in a dialog. The scroll area will eventually display a graph in a QSvgWidget, but only when the user clicks a button after possibly changing some parameters.
The placeholder label is in a grid layout so that it is centered horizontally and vertically on the scroll area's child. I want to save the placeholder widget when I set the SVG widget so that later, if parameters are changed after the graph has been shown once, that I can replace the SVG widget with the placeholder and then re-generate the graph again.
The docs seem straightforward about it ... if I call
QScrollArea::takeWidget(), the caller assumes ownership of the widget returned in the pointer. When I set the widget in the scroll area again, the scroll area assumes ownership. But who (or what) owns the QGridLayout? The SVG widget should not be in a layout because it can be scaled or zoomed, and it will be resized programmatically. If I call
takeWidget, does the grid layout come along with it? Or do I need to create it again when I use the placeholder a second time?
JonB last edited by
But who (or what) owns the QGridLayout?
What was its parent when created?
If I call takeWidget, does the grid layout come along with it?
If a widget is owned by another widget, it goes with that widget.
What about a simpler solution ? You can use a QStackedWidget so you just switch between your label and the other widget you want to show.
@JonB -- Thank you, you have answered my question perfectly! My ui_ header file tells me that the grid layout is indeed owned by the child widget of the scroll area. So it shouldn't be a problem.
But @SGaist has given me another good idea which will be simpler to implement and clearer for those following me to understand what is happening here. I will give that a try.
@SGaist -- thank you! This seems like a better solution, although @JonB has given me a good answer. I shall try your suggestion, because it is clearer for those people who will eventually have to maintain my code.