New UI widgets elements inaccessible to code model
-
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.
-
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.
@cristian-adam Thank you for the follow-up. I was reading about this old way yesterday, but I was not sure if it would make any difference.
Noting that CMake mark that generic command "qt_wrap_ui" as deprecated.
One should use qt6_wrap_ui which is supposedly provided by the Qt installation of CMake. (or the qt5 variant as required)
I will experiment with this in the meantime, and it appears promising!, while waiting for an official word from the Bug Report. If AUTOUIC is not terribly useful in it's current state, I am in hopes that it will be "fixed" to do what this manual qt6_wrap_ui accomplishes.
-
Confirming changing to the qt6_wrap_ui method seems to work "normally". The bug under which mine was closed as a duplicate shows Fixed on the Kanban board, so looking forward to finding out soon.
-
T ThirdStrand has marked this topic as solved on
-
Confirming changing to the qt6_wrap_ui method seems to work "normally". The bug under which mine was closed as a duplicate shows Fixed on the Kanban board, so looking forward to finding out soon.
The bug is fixed. You could get binaries from https://github.com/qt-creator/qt-creator/actions/runs/5763934496 when the job is done.
Or wait until the fix landed in https://download.qt.io/snapshots/qtcreator/11.0/