@SimonSchroeder said in What is a better IDE for QT:
So, I just need a single click after locating the line whereas in Qt Creator I need to first right click and then pick the correct menu entry and left click.
Point taken, so a little QoL issue :) Use/assign a keyboard shortcut and you are down to one click (or move cursor to line with arrow keys) and one keypress :)
I use cmake on VS 2022, but I'm not an expert. It feels very beta-ish. When something does not work, I try one of the two:
Restart VS2022
Make a cmake build into the same build folder using Qt Creator. That updates CMakeCache.txt, and suddenly VS2022 knows what to do.
Unfortunately, I don't have a deeper understanding of what's going on here...
@JoeCFD Thank Joe. from your answer, I do some research and I got that.
Qt Multimedia is additional library so I need to install it from Qt maintenance tool.
[image: b55e6fa1-f1be-4542-adbc-9875a542c6eb.png]
And follow your instructions
[image: 4cea74f8-fc84-4214-ba1a-17dfcdcc9d40.png]
Done
[image: ac183a67-e3c8-4ba1-9ca0-0aca84fdc0e7.png]
Thanks
It looks like it's statically building. When I go into the directory, inside the bin folder there is no dlls, when I do the lib /list some.lib, it shows how .obj files instead of .dll files. Weirdly enough, when I statically compile with the dynamic dll version of QT, it compiles fine, although it still requires the dlls.
It's not related to Qt or windeployqt and it's not about how the exe is made. Windows has a defined search order when it loads linked dynamic libraries. Other dlls, like plugins or resources, that load later on demand can be relocated via qtconf file.
In short - that's just how Windows organizes dlls.
You can fiddle with the local startup environment e.g. make a batch script that adds the dependencies subdirectory to PATH or changes working dir and you'd start your app by running it, but it's quite unusual and ugly.
I'd say just get used to having bunch of dlls next to your exe, even if it's not to your taste. That's what Windows apps do.
It goes by a different name in the VS Tools. When you're not building with qmake there's no pro file and no CONFIG. You configure individual parameters of the tools used in the build process.
For this particular option go to the project properties -> Qt Resource Compiler -> rcc and the option is called "Two-Pass Mode" here. Set it to Yes.
We have a little more information regarding our problem.
When using Visual GDB to create a new QT project for Raspberry PI, if the toolchain folder ‘C:\SysGCC\raspberry\Qt\v5-CMake’ doesn’t exist or is empty, the QT build tools are automatically downloaded and installed. The problem we are seeing is that the build tools end up being a different version (Qt v5.15.2) than what is being used on our target Raspberry Pi platform (Qt v5.12.3). This results in the following error produced by the moc compiler indicating that its attempting to compile using the much newer header libraries.
LinuxProject1_autogen/EWIEGA46WW/moc_MainWindow.cpp:80:18: error: 'QMetaObject::SuperData' has not been declared
QMetaObject::SuperData::link<QMainWindow::staticMetaObject>(),
^~~~~~~~~
LinuxProject1_autogen/EWIEGA46WW/moc_MainWindow.cpp:80:65: error: expected primary-expression before ')' token
QMetaObject::SuperData::linkQMainWindow::staticMetaObject(),
Is there anything we can set in Visual Studio or elsewhere that will insure the downloaded Qt build tools match the Qt version on the target board?
This is our development environment
Windows 10
Visual Studio 2017
Qt Visual Studio Tools Version 2.8.1.6
Visual GDB 5.6R2
Qt build tools vers 5.12.3
And we are targetting Raspberry PI OS vresion Raspbian 10.
We are working around this problem by manually copying the odler set of build tools into ‘C:\SysGCC\raspberry\Qt\v5-CMake’ before making a new project using VisualGDB. We were fortunate that we had an older set of Qt build tools on another development PC to copy these from. This is not a good long term solution for us.
@sbartolett said in Undeclared QMetaObject::SuperData:
Not sure if this error is caused by an incompatibility of versions or not. T
At leasr you should not mix them. Remove the 5.15.5 stuff from your build system (did not say what you're using).
@tuzepoito said in How do I use Qt headers in a CMake sub-project?:
I think I have a solution, or maybe a workaround.
Why workaround? If you want to use a library, you have to link against it what you're doing now - how should this be a workaround?
To solve the VCINSTALLDIR problem, start the command prompt from your start menu -> Visual Studio 2017 -> x64 Native Tools Command Prompt (be sure not the ones with x86)
Then call :
set PATH=C:\Qt\5.14.1\msvc2017_64\bin;%PATH%
to make both vc and qt dirs in your PATH.
To force deploying the release binaries, add --release after windeployqt.