Adding UI elements to a form is not propagated to the code

[In Fo]

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?

[Christian Ehrlicher]

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

[kshegunov]

@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 uic works, it doesn't do any magic, just saves you from typing a lot of stuff by giving you nice easy to click interface.

[In Fo]

@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?

[kshegunov]

@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"?

[In Fo]

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?

[kshegunov]

@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

[In Fo]

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?

[artwaw]

@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.

[In Fo]

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.

[In Fo]

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.

[artwaw]

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 pattern ui_[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.

[In Fo]

@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.h

What 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]

@In-Fo We learn every day - I checked and you are right.

[Christian Ehrlicher]

@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.

[In Fo]

@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]

@In-Fo The clang code model will underline the include statement

[AnneRanch]

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

[kshegunov]

Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?

[In Fo]

@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?

[Christian Ehrlicher]

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...

[In Fo]

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.

[kshegunov]

@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 .ui form file's name uic uses exactly as a name to generate the header file. That is:

myFormName.ui >> ui_myFormName.h

The 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 uic overwrites 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.

[AnneRanch]

@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...

[JonB]

@In-Fo said in Adding UI elements to a form is not propagated to the code:

Qt claims to be multiplatform but it is not mindful of the case sensitivity of files that it auto-generates behind the scenes.

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?

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.

Are you able to reproduce the "file's name changed along the lifetime of the project"? So far as I am aware, the only time Qt Creator auto-generates a filename is when you add a new class via the wizard, and at that point it makes the case of the filename all lower case, at least under Linux presumably so case is consistent. If you then, for example, change the spelling of the class name without doing it via Creator's Rename they may get out-of-sync.

[kshegunov]

@AnneRanch said in Adding UI elements to a form is not propagated to the code:

@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...

None of which is actually an answer to my question. But doesn't matter, there's no need for the snide remarks, I did only ask out of curiosity.

@JonB said in Adding UI elements to a form is not propagated to the code:

Are you able to reproduce the "file's name changed along the lifetime of the project"? So far as I am aware, the only time Qt Creator auto-generates a filename is when you add a new class via the wizard, and at that point it makes the case of the filename all lower case, at least under Linux presumably so case is consistent.

This is for sources/headers/form files/resources etc. In any case there's the option to correct the file name before creating the file. Here it's about the ui_<formname>.h which is generated by the uic.