Adding UI elements to a form is not propagated to the code
-
Internet is full of shock and horror stories of how Qt developers add UI elements to forms and how they are then unable to reference them from their code. Their solutions differ from running Qmake to deleting ui_<form name>.h file and other such things.
But their forum posts etc are somewhat dated and before I start messing with auto-generated files, I wanted to ask what is the currently suggested methods for getting project to build as of Qt Creator 4.7.2 that I am using?
-
What exact problem do you have? Use qmake or cmake as buildsystem and you're fine (even with Qt4)
btw: QtCreator 4.7 is somewhat outdated but has nothing to do with creating ui_.h files from .ui forms
-
@In-Fo said in Adding UI elements to a form is not propagated to the code:
Internet is full of shock and horror stories of how Qt developers add UI elements to forms and how they are then unable to reference them from their code.
That can be said of many things on the internet, including but not limited to microwave ovens, 5G, ultrasound, X-rays and so on. Not knowing how something works makes people fear it, but it's a poor excuse for not knowing how something works, especially in this day and age. My advice - read up in the docs how the
uicworks, it doesn't do any magic, just saves you from typing a lot of stuff by giving you nice easy to click interface. -
@Christian-Ehrlicher
I do not use anything that Qt Creator is not using. I install it, it detects kits, and I write code. If Qt Creator is there, the expectation is that it works. If it does not, there should be telltale warnings put in that some actions require manual actions outside of Qt Creator.For example, every time Qt Creator saves the <name>.ui file, there should be a message appearing "Run program X with parameters Y and Z". Otherwise the purpose of Qt Creator as an IDE is thoroughly defeated. I am left wondering, what is missing, and what has to be done, until I waste time searching online, not finding answers, and going to the forums to ask questions and waiting for answers.
Compare this to Visual Studio, where if you add a GUI element to a form, it becomes instantaneously available to the code. There is no longer excuse that Qt Creator is free whereas VS is not. It is actually, the other way around in some environments.
Bottom line is, I do not know what it means to use qmake or cmake as buildsystem because Qt Creator does something behind the scenes. I assume that it calls qmake under some circumstances, but not all. Anyhow, I ran qmake from the Build menu a number of times, but it does not bring the <form name>.ui in sync with the code. Nothing changes. So what manual step is required after adding a UI element to a form?
-
@In-Fo said in Adding UI elements to a form is not propagated to the code:
Compare this to Visual Studio, where if you add a GUI element to a form, it becomes instantaneously available to the code.
In C++? How and what do you mean by "available to the code"?
-
Double-click on the <form-name>.ui file under Forms.
Add a new combo box.
Save, close.
Double click on the <form-name>.cpp
Type the object name of the combo box. It is not declared/defined/visible/available, whatever term you prefer.So, holy wars aside, what manual actions have to be taken in order for the <form-name>.cpp file to gain access to the newly created combo box in its .ui file?
-
@In-Fo said in Adding UI elements to a form is not propagated to the code:
So, holy wars aside, what manual actions have to be taken in order for the <form-name>.cpp file to gain access to the newly created combo box in its .ui file?
I'm not on a crusade, but since I don't use VS, I don't know what's the workflow.
Here's the link:
https://doc.qt.io/qt-5/designer-using-a-ui-file.html#the-direct-approach -
The link above talks about setting up a new designer file and consuming it in a new application, so it seems.
My application already has a .ui file and it is already included in the <form name>.h
I presume that this follows "direct approach".
So my assumption is that changes in <formname>.ui should reflect in ui_<formname>.h at some point. What has to be done for the changes to .ui to propagate to the .h? -
@In-Fo Usually changes are propagated instantly. It is my experience though, that (especially on macOS, less often on Windows) with larger codebase to work with whatever background process responsible runs there providing the service seems to be laggy. My simple solution - build the form again enforcing rebuilding of ui_(...).h file.
I never considered it a problem serious enough to search for any kind of solution. -
I think I get it.
There are 2x ui_.h files under my project.
The new one is being generated as ui_newform.h
The old one included in the project is ui_newForm.h
Needless to say that the class name is actually newForm.
This is why the changes I am trying to introduce are not visible in the project.
It is a bug somewhere that butchers the class name. -
Yes, turns out that Makefile and compile_commands.json had a mix and match of newForm with newform. It does not matter under Windows but under Linux this leads to a ton of frustration. Qt Creator and qmake developers should be more careful by being mindful of case sensitivity of UNIX flavors vs Windows.
-
Whatever you found I think your conclusions are in error. Windows run on case sensitive system for about 20 years now (starting with XP, when NTFS 5.1 became a standard).
I run through all my projects using UI on both Windows and macOS (where I have case sensitive FS as well), in every single case header file filename conforms to the ui filename following the patternui_[caseSensitiveClassName].h.
I have no idea why this doesn't seem the case with your project but if it is Qt then it is limited to your particular configuration. -
@artwaw said in Adding UI elements to a form is not propagated to the code:
Whatever you found I think your conclusions are in error.
They are not. You are confusing case-sensitive-friendly filesystems with case sensitivity of file operations.
In Windows, go to an empty directory or create a new one.
Then issue the following commands:echo 1 > ui_newForm.h
echo 2 > ui_newform.hWhat does ui_newForm.h now contain, 1 or 2? It contains 2 because for Windows, both files are one and the same, and you still have only 1 file: ui_newForm.h, whereas ui_newform.h is nowhere to be found.
Now, try the same commands in Linux. You will end up with 2x different files with different contents.
-
@In-Fo said in Adding UI elements to a form is not propagated to the code:
Qt Creator and qmake developers should be more careful by being mindful of case sensitivity of UNIX flavors vs Windows.
No, you should simply care on windows for such stuff too. QtCreator even warns about such wrong includes.
-
@Christian-Ehrlicher said in Adding UI elements to a form is not propagated to the code:
QtCreator even warns about such wrong includes.
It has certainly neglected to warn me. What is the mechanism that it should warn through?
-
@In-Fo The clang code model will underline the include statement
-
After almost two cruelling months of using QtCreator / QtDesigner I feel an urge to contribute to this "holy war".
I will admit UP FRONT - I do not RTFM BEFORE i code - besides most of the doc are cookie cutters / repetitive and GENERALLY lack good examples - especially for QtDesigner. ( YES i picked Qt for GUI application. )So here is my "contribution" -
implement "connect" in QtDesigner and then find it in YOUR code!
Implement "SLOT" and associated "SIGNAL" then muddle thru the code...
Don't "connect" SLOT and SIGNAL belong to the SAME family to accomplish the task ?
But it is not only "connectivity" which is a big stumbling block in learning to use Qt, it is the lack of comprehensive explanation on how things interact. My favourite .pro "file" etc. ( I have brought this subject on before - so I won't repeat it here.)Cheers END OF RANT
-
Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?
-
@Christian-Ehrlicher
Which include statement? Do you seriously expect all developers scan 100% of our projects for something underlined, after running into a problem like above?
Bottom line is that if an IDE auto-generates (itself) or outsources auto-generation of some internal files to another tool (that is a part of vendor's toolchain) then both have to be mindful of the platforms that they claim to multiplatform on.Qt claims to be multiplatform but it is not mindful of the case sensitivity of files that it auto-generates behind the scenes. How do you envision developers in a teem cooperating from Windows and Linux machines, when the same project that they work on has incompatible auto-generated files, like in my case?
If a form class is camel-cased, tools on either platform must obey camel-casing and auto-generate files consistently. Is this too much to ask for?
