setupUi

smbika

Hi, I am an old (62) newbie here with tons of experience in C++ but almost none with Qt. I am trying to come up to speed on a huge multi-project piece of code which features a lot of dialogs and, because of Covid-19, I am teleworking with no real support other than overworked co-workers, google, and Qt documentation. I've seen a question which partially answers some of mine and I hope this doesn't upset anyone that I'm repeating something but here goes:

I created a dialog using the template wizard which comes with a QDialogButtonBox which has an OK and Cancel button. Here is the code it gave me:

header file:

#ifndef UIDIALOGTEST_H
#define UIDIALOGTEST_H

#include <QDialog>

namespace Ui {
class DialogTest;
}

class DialogTest : public QDialog
{
    Q_OBJECT

public:
    explicit DialogTest(QWidget *parent = nullptr);
    ~DialogTest();

private:
    Ui::DialogTest *ui;
};

#endif // UIDIALOGTEST_H

cpp file:

#include "ui-dialog-test.h"
#include "ui_dialog-test.h"

DialogTest::DialogTest(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::DialogTest)
{
    ui->setupUi(this);
}

DialogTest::~DialogTest()
{
    delete ui;
}

I'm using:

Qt Creator 4.13.0
Based on Qt 5.15.0 (MSVC 2019, 64 bit)

Built on Aug 25 2020 10:06:59 and

MingW...something

The first thing Qt Creator's Editor Intellisense told me was that I have an ui-dialog-test.cpp:6:12: error: allocation of incomplete type 'Ui::DialogTest'
ui-dialog-test.h:7:7: note: forward declaration of 'Ui::DialogTest'

Which I figured out meant the absence of a body and declaration for "setupUi"

So I made one. Not sure if I should have but I got it to compile. I note the call in the constructor to it hangs off of the member function "ui" which is the same type as the class. Interesting but explained in the aforementioned question I found. I did not find anything on the net as to what the argument is though I assumed it was, again, the class type. Could have been a generic QWidget.

So, why was this omitted from the code the wizard generated?

Thanks, after I figure this out or someone can tell me, I'll come back with how to get it to not abort the program.

Much obliged!
Smbika

[Added code tags ~kshegunov]

JonB · Built on Aug 25 2020 10:06:59 and

@smbika
Hi and welcome.

I'm a bit lost as to what you are saying happened to you. But, no, you shouldn't be creating your own setupUi() method. You save the .ui file from Designer, and when you do the build it runs the uic processor on that to produce a ui_....h file, which has setupUi() defined in it. Which you include into your .cpp file, and call ui->setupUi(this);.

That ui....h file is generated in the current build type's output directory, alongside the .obj files. So, if you're compiling for Debug into a debug directory somewhere, that's where the ui....h files are. If you look at one of them you will understand what is going on with your C++ knowledge.

I'm confused at your own ui-dialog-test.h file as well as the generated ui_dialog-test.h.

Start again, create a Qt Designer Form Class for the simplest Widget, name your class MyWidget so you are dealing with files named ...mywidget.... You should see that the mywidget.cpp generated from Designer starts with 2 include lines: #include "mywidget.h" & #include "ui_mywidget.h". You can make changes in mywidget.h & mywidget.cpp, but not in ui_mywidget.h. You access everything the Designer generated for the UI --- both the widgets and a method like setupUi() --- via ui->.... See where you get to.

P.S.
If you post code here, please use the forum's Code tag toolbar icon, or just put triple-backticks on line of their own before and after code you paste.

smbika

@JonB Jon, Thanks for the quick reply and I figured as much. I am in a complex system whose architecture may have prevented what you describe from happening but knowing now, for sure, that the setupUi is not for me to create helps quite a bit. I will soldier on and do what you suggest - fingers crossed :-)

Cheers,
Smbika

Kent-Dorfman

and most probably the folks who worked on it before you were also "coming up to speed" and misused many of features.

Chris Kawa

@Kent-Dorfman Not necessarily. Qt code generators are something that needs to be integrated into the entire workflow in projects. It's pretty automatic when you stick to the the couple of more popular solutions, but large projects have tendency to use custom solutions or heavily customized ones.
For example the project I work on currently is quite old and went through couple of different build systems and CI setups, and it always required some work to integrate Qt into it (Qt is used only in small part of the entire project and is not the main focus). Since all our build systems are either house made or heavily customized, at some point you had to specify which files go through moc and the rest of Qt tools in a separate config script. At other time you'd have to mark them with a special tag. This was later automated but is still quite different from what a simple hello world project created in Qt Creator and qmake would do and I fully expect that a person, even a seasoned Qt user, coming to the project fresh would feel lost if not for the documentation and help of coworkers.
If those things are not there and system is custom it can be difficult to grasp, so a good way to start is to understand what needs to happen and then work your way back to see how this is achieved in that particular setup. In this case, as @JonB described, what needs to happen is uic needs to run with the .ui file as input and spit out implementation of setupUi. The next step is to figure out how this is set up in that particular project - if it's automatic or needs some help from the developer.

smbika

@Kent-Dorfman Maybe not so much "misused" as "did the best they could flying blind ;-)

I'm slowly piecing together what they did and so far it's a chicken/egg scenario still: generate the ui first? how? create the class by hand?

It's a system that's been not so much evolving as accreting for more than 25 years with little forward guidance and NO documentation.

Sigh...

smbika

@Chris-Kawa Thanks for the insight. I think the system I am working on is similar in evolutionary history. There are just a few setupUi() methods in it and the rest of the uis are heavily wrapped in extended classes. I think all I need is that first clue but I may be able to suss it out myself. That would be nice...pat on the back sorta nice...:-)

Again, thanks! I appreciate the help!