setupUi organization

Match0um

Hi, I am working on a Qt project not developped by myself, and when looking at setupUi() of a window, It seems like it was not organized logically.

Here a small part of the code that I don't understand :

stackedWidget_pageCle = new QStackedWidget(tab_Axes);
stackedWidget_pageCle->setObjectName(QString::fromUtf8("stackedWidget_pageCle"));
stackedWidget_pageCle->setFont(font1);

gridLayout_6 = new QGridLayout(tab_Axes);
gridLayout_6->setObjectName(QString::fromUtf8("gridLayout_6"));
gridLayout_6->setContentsMargins(0, 10, 0, 0);
gridLayout_6->addWidget(stackedWidget_pageCle, 2, 0, 1, 3);

So in this example, tab_Axes has 2 children : stackedWidget_pageCle and gridLayout_6.
But stackedWidget_pageCle is added inside gridLayout_6. Is that logic ?

What is the difference between adding a parent while initilizing ("new Object(parent)") and "parent->addObject(object)" ?

Chris Kawa

A little redundant but nothing fundamentally wrong here.

A widget has children. It can also have a layout set (that becomes a child too) that manages geometry of its parent's children widgets. addWidget adds a child to the parent of the layout, not layout itself.

new QWidget(parent) - creates a widget and adds it as a child to the parent
new QXXXLayout(parent) - creates a layout, adds it as a child to the parent and sets it as the layout of that parent
layout->addWidget(widget) - adds widget as a child to the layout's parent widget and makes layout manage widget's geometry

So in this case you have:
stackedWidget_pageCle becomes a child of tab_Axes
gridLayout_6 becomes a child of tab_Axes and also becomes its layout meaning it will manage its children
stackedWidget_pageCle is added to the layout meaning it would become a child of tab_Axes, but it already is so nothing new happens here in terms of parent-child relationship

The result would be the same if the first line was

stackedWidget_pageCle = new QStackedWidget();

i.e. no parent, as it gets one when it is added to the layout.
The reason that it was written this way is probably because there's a mantra repeated over and over that you should always give parents to your QObjects and people do it out of habit without thinking if it's actually needed. It's not in this case but it doesn't hurt much either.

Christian Ehrlicher

@Chris-Kawa said in setupUi organization:

The reason that it was written this way is probably because

The reason is more that setupUi() is a generated function by uic :)

Chris Kawa

@Christian-Ehrlicher Hah, yeah, good point :) I forgot that part by the end :)

Match0um

Thank you for your answers !
The reason why I'm asking that, is that my window often crashes, because of the ui, but not always at the same point. So It's been days that I am investigating the issue with the ui.
Sometimes it crashes on a doubleSpinBox->setSuffix(...) (I have a lot of QDoubleSpinBox in my window, and it doesn't crash on the same one), but most of the time it is after
myWindow->show().
When I run the app in debug mode, this is what I always get when the app crashes :

1  RaiseFailFastException                                                                  0x7ffb20770c0f 
2  qt_message_fatal                                    qlogging.cpp                   1892 0x2125f454     
3  QMessageLogger::fatal                               qlogging.cpp                   887  0x2125fe2b     
4  qt_assert                                           qglobal.cpp                    3201 0x2125acd1     
5  QAccessibleWidget::window                           qaccessiblewidget.cpp          228  0x2ce8982f     
6  QWindowsUiAutomation::hwndForAccessible             qwindowsuiautils.cpp           89   0x3c243667     
7  QWindowsUiaMainProvider::get_HostRawElementProvider qwindowsuiamainprovider.cpp    434  0x3c238689     
8  UiaHostProviderFromHwnd                                                                 0x7ffaed52f003 
9  UiaHostProviderFromHwnd                                                                 0x7ffaed5307d3 
10 UiaHostProviderFromHwnd                                                                 0x7ffaed52ec5a 
11 UiaRaiseAutomationEvent                                                                 0x7ffaed52d744 
12 UiaRaiseAutomationEvent                                                                 0x7ffaed52d3fc 
13 QWindowsUiaWrapper::raiseAutomationEvent            qwindowsuiawrapper.cpp         113  0x3c2ef364     
14 QWindowsUiaMainProvider::notifyFocusChange          qwindowsuiamainprovider.cpp    109  0x3c237267     
15 QWindowsUiaAccessibility::notifyAccessibilityUpdate qwindowsuiaaccessibility.cpp   108  0x3c236a8e     
16 QAccessible::updateAccessibility                    qaccessible.cpp                875  0xf57569c      
17 QWidget::setFocus                                   qwidget.cpp                    6581 0x2cca44d2     
18 QApplication::setActiveWindow                       qapplication.cpp               2123 0x2cc6d2e0     
19 QApplicationPrivate::notifyActiveWindowChange       qapplication.cpp               2168 0x2cc6d3a1     
20 QGuiApplicationPrivate::processActivatedEvent       qguiapplication.cpp            2329 0xf59827f      
21 QGuiApplicationPrivate::processWindowSystemEvent    qguiapplication.cpp            1858 0xf59c895      
22 QWindowSystemInterface::sendWindowSystemEvents      qwindowsysteminterface.cpp     1151 0xf580503      
23 QWindowsGuiEventDispatcher::sendPostedEvents        qwindowsguieventdispatcher.cpp 82   0x3c246f39     
24 qt_internal_proc                                    qeventdispatcher_win.cpp       245  0x2143c219     
25 USER32!CallWindowProcW                                                                  0x7ffb22745c1d 
26 USER32!DispatchMessageW                                                                 0x7ffb22745612 
27 QEventDispatcherWin32::processEvents                qeventdispatcher_win.cpp       639  0x2143b98d     
28 QWindowsGuiEventDispatcher::processEvents           qwindowsguieventdispatcher.cpp 74   0x3c246f17     
29 QEventLoop::processEvents                           qeventloop.cpp                 138  0x213e5e27     
30 QEventLoop::exec                                    qeventloop.cpp                 225  0x213e6245     
31 QCoreApplication::exec                              qcoreapplication.cpp           1363 0x213eee1a     
32 QGuiApplication::exec                               qguiapplication.cpp            1779 0xf5923bf      
33 QApplication::exec                                  qapplication.cpp               2893 0x2cc68070     
34 qMain                                               main.cpp                       117  0x4027c9       
35 WinMain                                             qtmain_win.cpp                 97   0x7b773a       
36 __tmainCRTStartup                                                                       0x4013c7       
37 WinMainCRTStartup                                                                       0x4014cb

Another thing I found weird in the code is that part :

    ui->setupUi(this);
    ConfigGUI::configView(this);
    this->setWindowTitle("Fiche Serrure");

    WidgetStacked* widgetStacked = new WidgetStacked();
    ui->gridLayout_pageVisible->addWidget(widgetStacked);
    widgetStacked->setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Expanding);
    widgetStacked->addWidget(ui->page_axe1);
    widgetStacked->addWidget(ui->page_axe2);
    widgetStacked->setCurrentIndex(0);

This lines are in the constructor.
page_axe1 and page_axe2 are already affected to a widget in setupUi() :

page_axe1 = new QWidget();
page_axe1->setObjectName(QString::fromUtf8("page_axe1"));
stackedWidget_pageCle->addWidget(page_axe1);

page_axe2 = new QWidget();
page_axe2->setObjectName(QString::fromUtf8("page_axe2"));
stackedWidget_pageCle->addWidget(page_axe2);

Is it ok to do that ?