Using QT for some time has been used in the IDE environment (Qtcreator and vs2003+ integrators), which naturally has a lot less troublesome steps. But while enjoying this convenience, we also lost the understanding of more knowledge behind the drip. In the IDE, if we are going to develop a dialog box, usually using the new->QT->QT Designer interface class, the IDE will automatically generate three files for us (Filename.ui, filename.h,filename.cpp). Qmake is also very intelligent and can automatically detect this user interface file (filename.ui) and produce the appropriate makefile rules. This way, before compiling, the IDE automatically calls the UIC (the QT-brought UI compiler, user Interface Compiler) to convert the interface file (Filename.ui) to C + + code and save it in the Ui_filename.h file. The classes in the ui_filename.h (which are typically defined under the namespace UI) are used in a combination (that is, a delegate or proxy) in another two C + + source files (filename.h and Filename.cpp).
If you don't take the initiative to look at the details, you may never understand this, even if you've been using QT for years. At one time, the requirements of the project team of our developers do not make the interface layout is not appropriate, beautiful. So I had the idea to develop the interface myself. Very good! The developer quickly took the time to teach the demand staff to design the form interface with QT Designer, however, when the demand staff threw the Pureui_filename.ui file to our developers, we suddenly got a silly eye and how to use it. So the most stupid of course is the simplest way: or the same as before, through the IDE "New->QT->QT Designer Interface class" generated with "pureui_filename." file with the same name, and replace the IDE's auto-generated *.ui file with the pureui_filename.ui that the requirement person gives. Although turned a small bend, but the purpose reached!
After thinking about it, I always felt a little sorry, so I looked at the QT document Using a Designer UI File in Your application
In this document, the methods for using UI files in your application are described in detail.
A direct approach (the approach)
That is, the Filename.ui through UIC converted C + + code file Ui_filename.h directly included, using its inside the UI namespace of the class (the name and the main form of the objectname is the same, this is assumed to be gotocelldialog).
#include "ui_gotocelldialog.h" //UIC tool will gotocelldialog.ui generated C + + code int main (int ARGC, Char *argv[]) { qapplication app (argc, argv); qdialog *dialog= New Qdialog; //is used to display the parent form of the interface Qdialog (subclass of Qwidget) Ui::gotocelldialog UI; //interface class, Must be displayed on a qwidget (or its subclasses) UI.SETUPUI (dialog); Set Qdialog to the parent form of gotocelldialog so that the controls defined inside the Gotocelldialog are displayed in the Qdialog pane Dialog->show ( ); return app.exec (); } II, single inheritance mode (the one inheritance approach) One-way inheritance is relative to the subsequent multiple inheritance, and the single-inheritance approach is also called the combination (that is, the delegate or proxy) way. The simple way to do this is to first customize a subclass in the code (for example, the Gotocelldialog class in the following), which derives from the form class (or its compatible subclasses) that corresponds to the forms, and uses the UI-generated class to define a member variable in a class that can be a value or a pointer , it is divided into two forms: Member variable and pointer member variable, depending on the form of member variable. This makes it convenient to use the variables and functions in the UI and UI directly in the Gotocelldialog constructor. 1, using member variables upcoming Ui::gotocelldialog Ui; A member variable that is a class Gotocelldialog (inherits only from Qdialog, single inheritance). There's a little value here.It is important to note that the UI file provides classes that are included in the name space named UI, which is intended to separate the UI file's namespace from the user's code and avoid naming conflicts between the two. Header file: gotocelldialog.h #include <QDialog> #include "ui_gotocelldialog.h"//because it is a member variable form, it must contain the corresponding header file class gotocelldialog:public qdialog { Q_OBJECT public: Explicit Gotocelldialog (Qdialog *parent = 0) private slots: void on_lineedit_ TextChanged (); private: ui::gotocelldialog ui; }; implementation file: Gotocelldialog.cpp #include "gotocelldialog.h" #include <qtgui> gotocelldialog::gotocelldialog (Qwidget *parent ) : Qdialog (parent) { UI.SETUPUI (this), qregexp regExp ("[A-za-z][1-9 ][0-9]{0,2} "); Lineedit->setvalidator (New Qregexpvalidator (REGEXP, this)); Connect (OKButton, SIGNAL (clicked ()), slot (Accept ())); Connect (CancelButton, SIGNAL ()), slot ( Reject ()));} voidGotocelldialog::on_lineedit_textchanged () { //bool Hasacceptableinput () const //This Property holds whether the input satisfies the inputMask and the validator. /By default rue. okbutton->setenabled (Lineedit->hasacceptableinput ());} &NBSP;&NBSP;2, using pointer member variables Similar to member variables, the only difference is that Ui::gotocelldialog is declared as a pointer member, which is Ui::gotocelldialog * ui; therefore, the corresponding header file as long as the predecessor declaration can: namespace ui { class gotocelldialog; }//Pre-declaration, Include the corresponding header file only in the implementation file class gotocelldialog:public qdialog{ //ditto private:& nbsp; ui::gotocelldialog *ui; }; implement file: #include "ui_gotocelldialog.h" gotocelldialog::gotocelldialog (Qdialog *parent): qdialog (parent), UI (new UI:: Gotocelldialog) { &NBSP;UI->SETUPUI (this); } calculatorform::~ CalculatorForm () &NBSP;{&NBsp delete UI; Remember to delete, release resources } Three, multiple inheritance (the multiple inheritance approach) Multiple inheritance is a custom class that derives multiple derivations from the form class and the UI class. Look at the code.: header File: #ifndef gotocelldialog_h#define gotocelldialog_h #include <QDialog> #include "UI _gotocelldialog.h " class gotocelldialog: public qdialog, public ui::gotocelldialog{ Q_OBJECT& nbsp;public: Explicit Gotocelldialog (Qwidget *parent = 0); private slots: void On_ Lineedit_textchanged ();}; #endif//gotocelldialog_h Implement file: #include "gotocelldialog.h" #include <QtGui> gotocelldialog::gotocelldialog (Qwidget *parent) : Qdialog (parent) { THIS->SETUPUI ( this); 1th this refers to Ui::gotocelldialog, 2nd this means (Qdialog) namely Ui::gotocelldialog->setupui (Qdialog) Qregexp regExp ("[a-za-z][1-9][0-9]{0,2}"); Lineedit->setvalidator (New Qregexpvalidator (REGEXP, this )); &NBSp Connect (OKButton, SIGNAL (clicked ()), slot (Accept ())); Connect (CancelButton, SIGNAL ()), slot ( Reject ()));} void gotocelldialog::on_lineedit_textchanged () { //bool Hasacceptableinput () const // The holds whether the input satisfies the inputMask and the validator. /By default is true. okbutton->setenabled (Lineedit->hasacceptableinput ());}
PS: About internationalization in the UI interface
If the user interface language sends a change, QT notifies the application by sending the Qevent::languagechange event. In order to invoke the Retranslateui () function to achieve the purpose of switching languages, we need to re-implement the Qwidget::changeevent () event handler inside the interface class.
Reacting to Language changes
Qt notifies applications if the user interface language changes by sending an event of the type Qevent::languagechange. To call the member function Retranslateui () of the user interface object, we reimplement qwidget::changeevent () in the form class, as follows:
void Calculatorform::changeevent (Qevent *e) {qwidget::changeevent (e); Switch (E->type ()) {case Qevent::languagechange:ui->retranslateui (this); Break Default:break; }} Source:
>In addition to working with UI files at compile time, QT also provides a mechanism for dynamically loading UI files at run time. The UI file can be loaded at run time through the Quiloader of the Qtuitools module.
The way the UI file is loaded is shown in the following code:
[CPP]View PlainCopy
- qwidget* Textfinder::loaduifile ()
- {
- Quiloader loader;
- QFile file (":/forms/textfinder.ui"); The //file name can be an absolute path or relative to the application's path
- File.Open (qfile::readonly);
- Qwidget *formwidget = Loader.load (&file, this );
- File.close ();
- return formwidget;
- }
How to use:
[CPP]View PlainCopy
- Ui_lineedit = qfindchild<qlineedit*> (Formwidget, "LineEdit"); //requires the name of the specified object the Quiloader class is placed in a separate library.
In order to use Quiloader in your application, you must include a line in the project file. Pro:
CONFIG + = Uitools
In the actual project, the need to dynamically load the UI file doesn't seem to be strong, and the project I've been through has never been used this way.
Source: >
How to use Qtdesigner to create a UI file in QT