QScrollArea::takeWidget() with the widget in a QGridLayout

Robert Hairgrove

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

@Robert-Hairgrove said in QScrollArea::takeWidget() with the widget in a QGridLayout:

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.

SGaist

Hi,

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.

Robert Hairgrove

@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.

Robert Hairgrove

@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.