Adding UI elements to a form is not propagated to the code
-
@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?
-
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? -
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.
-
@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.
-
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.
@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?
-
@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
-
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?
-
@In-Fo The clang code model will underline the include statement
@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?
-
It's your task to use the correct camel casing for all files. If you add a wrong include statement it's your fault. I don't see where the tools can help you here. It's as simple as using a wrong camel cased class name like Qdialog instead QDialog.
I still don't have a valid case where you hit a problem though... -
Only if I create those files myself. If Qt Creator auto-generates them based on the class name of the file that I create, it is not my responsibility.
Auto-generated files have to be named correctly by the tool that auto-generates them. It should not be the responsibility of the tool's user to double-check that it does its job properly.
When the tool auto-generates files with the correct name sometimes, or only on some OS's but not on others, it is not fulfilling its stated purpose.I'll repeat: the file's name changed along the lifetime of the project from the one that matched the underlying class's name to the one that no longer matches it. None of the developers has visibility into the name that the tool uses behind the scenes to auto-generate that file. It is probably not productive to blame me for that. The tool has to work consistently across all platforms that Qt Creator claims to support.
-
Only if I create those files myself. If Qt Creator auto-generates them based on the class name of the file that I create, it is not my responsibility.
Auto-generated files have to be named correctly by the tool that auto-generates them. It should not be the responsibility of the tool's user to double-check that it does its job properly.
When the tool auto-generates files with the correct name sometimes, or only on some OS's but not on others, it is not fulfilling its stated purpose.I'll repeat: the file's name changed along the lifetime of the project from the one that matched the underlying class's name to the one that no longer matches it. None of the developers has visibility into the name that the tool uses behind the scenes to auto-generate that file. It is probably not productive to blame me for that. The tool has to work consistently across all platforms that Qt Creator claims to support.
@In-Fo said in Adding UI elements to a form is not propagated to the code:
Only if I create those files myself. If Qt Creator auto-generates them based on the class name of the file that I create, it is not my responsibility.
The class name has nothing to do with the generated file, which is also in the docs mind you. The
.uiform file's nameuicuses exactly as a name to generate the header file. That is:myFormName.ui >> ui_myFormName.hThe include:
#include "ui_myformname.h"works on windows (but not on linux), just because windows is case-aware, but case-insensitive. It is not the fault of the toolchain for a decision made by the os vendor a long, long time ago, be it that good or bad. If you have had the file generated once and only then changed to camel-case name the OS, the toolchain or anything that uses the OS's API can't distinguish, so
uicoverwrites the file with the old name ... solution is to simply remove the old file and re-generate it, that's your job though, no automation can do anything 'bout it. -
Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?
@kshegunov said in Adding UI elements to a form is not propagated to the code:
Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?
Wrote my first program in 1973 - in assembly.
Wrote couple of C programs in 1987 - before Windows .
Was Q&A analyst for Visual Basic software ...
NO, I do not have a foggiest idea about programming...
