QT Quest--on the use of UI files

A friend who believes in Qt designer is no stranger to the. ui files in QT project. This file does not directly modify its source code in Qt Designer, but can only be manipulated by the QT designer's graphical tools. For this, I have to praise the person who designed QT designer, because it greatly avoids the possibility of syntax errors in the UI file, while allowing programmers to save a lot of programming interface design time and thus shorten the development of the whole program project.

On the other hand, the reason I want to talk about this. ui file is because this file is used differently from similar files used by many mobile development platforms today. From that point on, I think it's a pretty good innovation.

I'm sure everyone knows that every QT project is pure C + +, and if we open the. ui file with a normal document editor, we'll find that the. ui file is actually a custom tag XML file, so how does this file work for the whole QT project? is Qt's C + + compiler able to translate it directly into the C + + language and compile it? With this problem, I explored and found another result.

We can first use QT creator to create a GUI Project with a UI file, and QT Creator will let us choose whether this window class is based on Qmainwindow, Qwidget, or qdialog in the process of creation. Let's pick one, and here I choose Qmainwindow. Then we can get 5 files, a. Pro file, A. ui file, A. h file, and two. cpp files, one of which is main.cpp, which contains the entry function of the QT program, Main.

And then, if we open the. h file, we'll see a statement like this:

Namespace Ui {

Class MainWindow;

}

  This means that there is a class called MainWindow in the namespace UI, but the description of this class is not clear, but certainly not in the current. h file. However, we can find in the following class descriptions that there is a private pointer to the Ui::mainwindow, and since that is the case, the UI should be found in the corresponding. cpp file: MainWindow describes the. h file, as expected, in the corresponding. cpp, this file is found:

  #include "ui_mainwindow.h"

  However, if you do not have a build at this point, you will find that this file is not found, then we will build this project. We can see the file after the result is a build. After opening, we will see the description of Ui::mainwindow:

Namespace Ui {

Class Mainwindow:public Ui_mainwindow {};

}//Namespace Ui

  This is the description of the class, short and lean, and on top of it is the description of the Ui_mainwindow class, and this ui_mainwindow is exactly what the. ui file is designed to be generated by the UIC tool. So how does this class work?

  we know that in QT project, there are three ways to implement a window class, either inheriting Qmainwindow, inheriting Qwidget, or inheriting qdialog. There are two ways to use similar to the Ui::mainwindow class:

The  first approach: Suppose our real window class is called MainWindow, which inherits from Qmainwindow, then it can have a private member of Ui::mainwindow, and in the MainWindow constructor, instantiate this private UI: MainWindow, then calls this private Ui::mainwindow Setupui method, sets the MainWindow user interface interface, which initializes the MainWindow interface according to the design of the. ui file. In this way, a window of the interface designed by the. UI file is set up.

The  second method: Still assuming that our real window class is called MainWindow, it still has to choose a class in Qmainwindow,qwidget,qdialog to inherit. Unlike the previous method, the MainWindow class does not need a private member of the Ui::mainwindow class, but instead uses multiple inheritance in C + +, allowing MainWindow to inherit Ui::mainwindow at the same time. Just instantiate it when you want to use MainWindow, and call the Setupui method in its constructor.

  these two methods, under normal circumstances, although there is no difference in the appearance of the final window, but in the memory management mechanism, but there are different. In terms of the security aspects of memory management, I'm more inclined to use the latter method than Symbian. Because Ui::mainwindow is instantiated in the first method, it is not guaranteed that in the next constructor, it is possible for the constructor to exit abnormally due to insufficient memory, which in turn causes Ui::mainwindow to become a memory leak. Although QT has its own memory dumpster processing mechanism to solve the memory leak problem, but in the sense of personal, the efficiency of this mechanism will not catch up with the efficiency of human-freed memory.

  Another thing to say is that while many mobile development platforms are using XML-formatted files similar to. ui files as Windows interface design, there are two problems, first, there are many platforms that require programmers to directly write this XML-formatted file without a QT-like Designer's tool, which makes the programmer write a headache, and thus lost a lot of development time; second, there are few platforms like Qt This first to the XML format of the. ui file into C + + files and then compile, many are directly to the operating system, run the program to parse, After obtaining the corresponding data, the corresponding program interface can be produced, which will undoubtedly reduce the running efficiency of the program.

QT Quest--on the use of UI files