New UI widgets elements inaccessible to code model
-
QtCreator 11.0.0, running MingW-64 compiler. I disable Clang Code Model by default by de-selecting the plugin. Clang is just too slow. The default code model also handles "." vs "->" on object references intelligently, so I prefer it.
I have noticed in Qt 6.5 using CMake and the default code model (NOT Clang) that if I create a UI element in the designer pane and go back to the source code, that element is not available for code completion, and is generally just not recognized as existing to the code model.
Complete rebuilds of the project do not fix this. It is also compounded by the same behavior if a widget element is renamed ("objectName" is changed). It is not until QtCreator is closed and restarted that the project will recognize the new UI widget objects.
I am happy to be completely wrong and to have done a stupid human trick on the configuration somewhere, so please enlighten me. This is the first time since 2016 that I have run into this.
Regards,
Mitch -
As a test of my memory, I opened an existing qmake project, added a UI widget element to the designer form and saved the .ui file.
I went to the source code for that class and the element was immediately available to the code model for auto-completion.
-
As a test of my memory, I opened an existing qmake project, added a UI widget element to the designer form and saved the .ui file.
I went to the source code for that class and the element was immediately available to the code model for auto-completion.
Usually you have to build (so that moc/uic are executed) your project again after adding new stuff to your Designer UI file.
I would say, the model doesn't recognize the new widget because it's simply not there. The UI code has not been translated into the usable C++ header.
Soui->....
cant autocomplete, let's say,pushButton_1
. -
Usually you have to build (so that moc/uic are executed) your project again after adding new stuff to your Designer UI file.
I would say, the model doesn't recognize the new widget because it's simply not there. The UI code has not been translated into the usable C++ header.
Soui->....
cant autocomplete, let's say,pushButton_1
.@Pl45m4 I would have believed you if it hadn't worked in qmake by simply saving the .ui file. I think this "issue" lives in cmake somewhere.
-
@Pl45m4 I would have believed you if it hadn't worked in qmake by simply saving the .ui file. I think this "issue" lives in cmake somewhere.
In my qmake project I have to do it also.
There is some auto-build option in your project, which the other project doesnt have?
IIRC you can set something like "Build every time before run" in QtCreator.Without doing anything else, there is no way that your code model recognizes changes made to your UI file in QtDesigner...
Whole thing works by translating the XML style UI file into a compilable C++ header. If you add something to your UI file, which is not in your header, you cant use it without rebuilding your app.
How else should this work?!If you know the object name and you type it yourself, you can edit the UI, change your code and "build + run". Then it works, but you dont have model autocompletion support until you run your app at least once.
-
In my qmake project I have to do it also.
There is some auto-build option in your project, which the other project doesnt have?
IIRC you can set something like "Build every time before run" in QtCreator.Without doing anything else, there is no way that your code model recognizes changes made to your UI file in QtDesigner...
Whole thing works by translating the XML style UI file into a compilable C++ header. If you add something to your UI file, which is not in your header, you cant use it without rebuilding your app.
How else should this work?!If you know the object name and you type it yourself, you can edit the UI, change your code and "build + run". Then it works, but you dont have model autocompletion support until you run your app at least once.
@Pl45m4 I am not saying that's not how it works internally, and what you said makes perfect sense. What I am saying is that in a qmake Widgets project, if you add a UI element, hit Ctrl+S, and go to the source for that object (Shift + F4), then you will likely see code completion for the new UI element. I always have (for 7 years) until trying to get on board with CMake.
I have never (knowingly) changed any settings having to do with qmake in the Qt Creator Preferences. All are defaults.
CMake is sort of a necessity by way of needing the new QProtobuf library, which uses CMake as the helper to compile the Qt style support classes for each .proto file.
In my CMakeLists.txt file, all of the .ui files are included in a list of all of the source .cpp and .h files. So CMake knows which files are in play.
To some it may seem that this is a trivial thing, but I switch back and forth between the UI editor and the source editor constantly as I add UI elements, then create and implement the slots for them on the spot. If the code model doesn't know about the new elements, this makes for a VERY slow process for something that is very intuitive and flows nicely when in qmake.
Perhaps there is some "CMake magic" to make it act like qmake does. Who knows?
-
@Pl45m4 I am not saying that's not how it works internally, and what you said makes perfect sense. What I am saying is that in a qmake Widgets project, if you add a UI element, hit Ctrl+S, and go to the source for that object (Shift + F4), then you will likely see code completion for the new UI element. I always have (for 7 years) until trying to get on board with CMake.
I have never (knowingly) changed any settings having to do with qmake in the Qt Creator Preferences. All are defaults.
CMake is sort of a necessity by way of needing the new QProtobuf library, which uses CMake as the helper to compile the Qt style support classes for each .proto file.
In my CMakeLists.txt file, all of the .ui files are included in a list of all of the source .cpp and .h files. So CMake knows which files are in play.
To some it may seem that this is a trivial thing, but I switch back and forth between the UI editor and the source editor constantly as I add UI elements, then create and implement the slots for them on the spot. If the code model doesn't know about the new elements, this makes for a VERY slow process for something that is very intuitive and flows nicely when in qmake.
Perhaps there is some "CMake magic" to make it act like qmake does. Who knows?
@ThirdStrand said in New UI widgets elements inaccessible to code model:
What I am saying is that in a qmake Widgets project, if you add a UI element, hit Ctrl+S, and go to the source for that object (Shift + F4), then you will likely see code completion for the new UI element.
And that is what I find weird...
I've added a
pushButton9
to my UI file, saved, went back tomainWindow.cpp
and tried to let the autocompletion recognize it... which it did not. The code compiles because there is apushButton9
in my case, but the auto-completion model didn't know about the new widget until I compiled/built once.
I dont know if my project settings are weird but (for me) it was always like this.
Note: I'm not using the latest version of QtCreator -
@ThirdStrand said in New UI widgets elements inaccessible to code model:
What I am saying is that in a qmake Widgets project, if you add a UI element, hit Ctrl+S, and go to the source for that object (Shift + F4), then you will likely see code completion for the new UI element.
And that is what I find weird...
I've added a
pushButton9
to my UI file, saved, went back tomainWindow.cpp
and tried to let the autocompletion recognize it... which it did not. The code compiles because there is apushButton9
in my case, but the auto-completion model didn't know about the new widget until I compiled/built once.
I dont know if my project settings are weird but (for me) it was always like this.
Note: I'm not using the latest version of QtCreator@Pl45m4 Ok is this a Qt5 vs. Qt6 issue then? I tested an older Qt5 project. I'll retest with a newer Qt6 qmake project and report back.
-
@ThirdStrand said in New UI widgets elements inaccessible to code model:
What I am saying is that in a qmake Widgets project, if you add a UI element, hit Ctrl+S, and go to the source for that object (Shift + F4), then you will likely see code completion for the new UI element.
And that is what I find weird...
I've added a
pushButton9
to my UI file, saved, went back tomainWindow.cpp
and tried to let the autocompletion recognize it... which it did not. The code compiles because there is apushButton9
in my case, but the auto-completion model didn't know about the new widget until I compiled/built once.
I dont know if my project settings are weird but (for me) it was always like this.
Note: I'm not using the latest version of QtCreatorThis post is deleted! -
This post is deleted!
This post is deleted! -
@Pl45m4 Ok is this a Qt5 vs. Qt6 issue then? I tested an older Qt5 project. I'll retest with a newer Qt6 qmake project and report back.
@ThirdStrand said in New UI widgets elements inaccessible to code model:
@Pl45m4 Ok is this a Qt5 vs. Qt6 issue then? I tested an older Qt5 project. I'll retest with a newer Qt6 qmake project and report back.
So I opened a qmake project and set the kit to Qt 6.5.2. I built it. Then I opened the main UI file and added a QLabel. Ctrl + S to save, Shift + F4 to go to the source code and the code model found the QLabel immediately. Same as happened in Qt5 qmake. AND THIS HAPPENS WITH THE clangd process running.
I cannot believe that I am the only one who has noticed this. Not being able to have code completion when adding UI elements severely slows down creation of UI projects.
-
@ThirdStrand said in New UI widgets elements inaccessible to code model:
@Pl45m4 Ok is this a Qt5 vs. Qt6 issue then? I tested an older Qt5 project. I'll retest with a newer Qt6 qmake project and report back.
So I opened a qmake project and set the kit to Qt 6.5.2. I built it. Then I opened the main UI file and added a QLabel. Ctrl + S to save, Shift + F4 to go to the source code and the code model found the QLabel immediately. Same as happened in Qt5 qmake. AND THIS HAPPENS WITH THE clangd process running.
I cannot believe that I am the only one who has noticed this. Not being able to have code completion when adding UI elements severely slows down creation of UI projects.
...
I cannot believe that I am the only one who has noticed this. Not being able to have code completion when adding UI elements severely slows down creation of UI projects.
INTERESTING:
The qmake project, when viewed in the "Tools/Debug QtCreator Code Model Inspector" (Ctrl+Shift+F12) shows both of my project's UI header files (ui_classname.h) as part of the Project Files tab.The cmake project with the same set of files, however, does NOT show them in the Project Files tab. If I explicitly add the ui_classname.h files to the cmake list of input files, there is no (discernable) activity when either of those two files change.
Next stop bug report unless someone has further information.
-
...
I cannot believe that I am the only one who has noticed this. Not being able to have code completion when adding UI elements severely slows down creation of UI projects.
INTERESTING:
The qmake project, when viewed in the "Tools/Debug QtCreator Code Model Inspector" (Ctrl+Shift+F12) shows both of my project's UI header files (ui_classname.h) as part of the Project Files tab.The cmake project with the same set of files, however, does NOT show them in the Project Files tab. If I explicitly add the ui_classname.h files to the cmake list of input files, there is no (discernable) activity when either of those two files change.
Next stop bug report unless someone has further information.
@ThirdStrand said in New UI widgets elements inaccessible to code model:
...
I cannot believe that I am the only one who has noticed this. Not being able to have code completion when adding UI elements severely slows down creation of UI projects.
INTERESTING:
...Next stop bug report unless someone has further information.
If clangd is turned off completely (confirmed not even running on the PC), the same behavior remains. Works in qmake, and doesn't work in cmake. This may have something to do with cmake and AUTOUIC perhaps????????
-
@ThirdStrand said in New UI widgets elements inaccessible to code model:
...
I cannot believe that I am the only one who has noticed this. Not being able to have code completion when adding UI elements severely slows down creation of UI projects.
INTERESTING:
...Next stop bug report unless someone has further information.
If clangd is turned off completely (confirmed not even running on the PC), the same behavior remains. Works in qmake, and doesn't work in cmake. This may have something to do with cmake and AUTOUIC perhaps????????
-
Hm... maybe somebody else will comment on this whole thing and possibly can reproduce it. Could be some weird config, could be a bug or some unhandled behavior...
Good luck ;-)Yes, I am of the same hopes. Bear in mind also that this is a fresh Win11Pro PC, a freshly installed QtCreator 11.0.0 and the universal installer downloaded and installed all of the kits. Totally stock standard Qt.
-
C Christian Ehrlicher moved this topic from General and Desktop on
-
@Christian-Ehrlicher Thanks for moving this topic around in attempts to get visibility. Much appreciated.
-
For the record as no noise here yet:
-
For the record as no noise here yet:
@ThirdStrand Have you noticed it is marked "Duplicate" of https://bugreports.qt.io/browse/QTCREATORBUG-28787 ?
-
and ::
https://bugreports.qt.io/browse/QTCREATORBUG-28787
appears to have been reported this past February.
-
The CMake project using
AUTOUIC
set toON
do not work.But if you don't use
AUTOUIC
it works as expected.I've changed a
hello-widgets-cmake
project like this:#set(CMAKE_AUTOUIC ON) qt_wrap_ui(UI_SRC mainwindow.ui) set(PROJECT_SOURCES main.cpp mainwindow.cpp mainwindow.h ${UI_SRC} ) target_include_directories(hello-widgets-cmake PRIVATE ${CMAKE_BINARY_DIR})
And got it working for me.