Loader generating header

Exotic_Devel

I'm using QUiLoader for some tests, I realize that after compiling, generates the header file (.h) of form.

If the instantiation is dynamic, why does generating this header?

MuldeR

Normally you use "UIC":http://qt-project.org/doc/qt-4.8/uic.html to generate a header file (.h) from your Qt Designer file (.ui). This header file is then compiled into your application, which happens at compile time, so the .ui file will not be needed at runtime. Alternatively you can use the QUiLoader class to dynamically generate the user interface from an .ui file at runtime. You would only do the latter, if you really need your application to generate the UI dynamically at runtime...

(I guess one use case for the QUiLoader class would be an application where you explicitly want the user to be able to modify the UI without re-compiling the application. But normally you just use the standard UIC approach)

Exotic_Devel

I am using QUiLoader, but the file (. Uí) is being compiled.

My code

@#include <QApplication>
#include <QWidget>
#include <QUiLoader>
#include <QFile>

#include "MainWindow.hpp"

int main (int argc, char *argv[])
{
QApplication app(argc, argv);

QUiLoader loader;
QFile file_ui("Forms/MainWindow.ui");
file_ui.open(QIODevice::ReadOnly);
QWidget *mainwindow = loader.load(&file_ui);
mainwindow->show();

/* MainWindow mainwindow;
mainwindow.show(); */

return app.exec();

}
@

After compilation, ui_MainWindow.h appears in the directory

MuldeR

As explained before, when using the QUiLoader class, the UI is generated directly from the .ui file, at runtime. You don't need a .h file, generated by UIC, in this case. Sure, you can still compile your .ui file into a .h file, using UIC, even when using the QUiLoader class. But it's just redundant & pointless ;-)

Or the other way around: If you already have compiled your .ui file into a .h file, using UIC, then you can just create your UI the usual way (using the generated header file) and you do not need to use QUiLoader class at all.

Recommended reading:
http://qt-project.org/doc/qt-4.8/designer-using-a-ui-file.html

SGaist

Hi,

AFAIK, if your ui file is listed in the FORMS variable in your pro file, then uic will be called on it so the header will be generated

Exotic_Devel

[quote author="SGaist" date="1400527319"]Hi,

AFAIK, if your ui file is listed in the FORMS variable in your pro file, then uic will be called on it so the header will be generated[/quote]

How to prevent it? editing ".pro"?

MuldeR

[quote author="Exotic_Devel" date="1400531897"][quote author="SGaist" date="1400527319"]Hi,

AFAIK, if your ui file is listed in the FORMS variable in your pro file, then uic will be called on it so the header will be generated[/quote]

How to prevent it? editing ".pro"?[/quote]

Yes. If you don't want your .ui file to be compiled into a header file, you can simply edit the .pro file and remove it from FORMS variable. But may I ask: Why do you want to use the QUiLoader method in the first place?

bq. FORMS A list of UI files to be processed by uic.

Exotic_Devel

For my need, UIC or QUiLoader would function, therefore, my choice is just to test QUiLoader.
You have now created an entire application in QUiLoad? What is your opinion?

MuldeR

I have never created an application using QUiLoader, I always use UIC. And I don't see why you would want to use QUiLoader, unless you really need the flexibility to load arbitrary .ui files at runtime. If, however, the .ui file is fixed at compile time, using UIC should give a better performance (the UI XML file doesn't need to be parsed at runtime!). That plus: Using the header file generated by UIC, accessing your individual Widgets is much more convenient. Having to lookup each Widget by its name, as is required with QUiLoader, isn't really nice for non-trivial applications, I assume...

@//Using UIC
ui->button1->doSomething();

//Using QUiLoader
QPushButton *button = formWidget->findChild<QPushButton *>("button1");
if(button)
{
button->doSomething();
}@

Exotic_Devel

Thank you all, sorry my bad english.