New UI widgets elements inaccessible to code model

ThirdStrand

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

Pl45m4

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 ;-)

ThirdStrand

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.

ThirdStrand

@Christian-Ehrlicher Thanks for moving this topic around in attempts to get visibility. Much appreciated.

ThirdStrand

For the record as no noise here yet:

https://bugreports.qt.io/browse/QTCREATORBUG-29465

JonB

@ThirdStrand Have you noticed it is marked "Duplicate" of https://bugreports.qt.io/browse/QTCREATORBUG-28787 ?

ThirdStrand

and ::

https://bugreports.qt.io/browse/QTCREATORBUG-28787

appears to have been reported this past February.

cristian-adam

The CMake project using AUTOUIC set to ON 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.

ThirdStrand

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

ThirdStrand

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.

cristian-adam

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/

ThirdStrand

Additional note:

I built a new CMake file (using a file from another project and editing it) for an existing qmake project and attempted to build it. All components built until it got to building the UI. For some unknown reason, the resulting "ui_mainwindows.h" file, which is in it's normal place in the build folder was not found by CMake.

I changed CMake to turning on AUTOUIC and it built properly. Then changed it back to the qt6_wrap_ui method and it continues to build properly.