Often, this is the cause for my problems.
In release mode, I must add -lqwt to LIBS, where in debug mode, -lqwtd should be added. Here a snippet of my .pro file:
Qt Code:
#LIBS+= -lqwt #Release LIBS+= -lqwtd #DebugTo copy to clipboard, switch view to plain text mode
Cheers, Bilderbikkel
If you are using a static Widget and not on purpose there is an easy solution. All you have to do is remove the parent class parenthesis.
Qt Code:
To copy to clipboard, switch view to plain text mode
change to
Qt Code:
To copy to clipboard, switch view to plain text mode
Man, this stupid thing just nailed me for two days. When I set up my release mode build in Visual Studio, I copied the list of libraries from the debug settings, then carefully edited all of the "d" suffixes off. On all but two libraries...Perhaps you compiled "xyz" in debug mode and application in release mode?
For the first day, I couldn't figure out what was happening - the app wouldn't even get into main(). You could see it start in Task Manager, then it immediately exited. No error message, no crash, nothing. Finally thought to link it with debug turned on, and saw the "QPixmap: Must construct a QGuiApplication first" message. Spent a wasted hour looking for QPixmap, and of course there aren't any defined as static in my code. Finally came across this thread and thought, "I wonder if I've been stupid..."
So, for anyone else using Visual Studio or the MSVC compilers to build your Qt projects, you can't mix debug and release libraries or debug libraries and a release executable. If you get the incomprehensible "QPixmap: Must construct..." error, it means that's what you've done.
d_stranz is right - I had all my libs with a 'd' at the end except for Qt5Widgets and it was causing an error in setupUi() that said: Must construct a QGuiApplication before QPixmap. Thanks for the tipoff guys!
Yes, but I continue to be stupid. This time, I had a bare-bones QApplication I had just written. Added a few lines to the MainWindow constructor to set some things up (pushing std:: wstring constants onto a std:: vector< std:: wstring > >) and it kept crashing with a heap corruption error. After another wasted hour, discovered it was a mismatch of release and debug libraries yet again.Thanks for the tipoff guys!
This nasty bug keeps appearing in different disguises. I guess the take-away lesson is that if you have perfectly good code that won't run, it has nothing to do with the code, it's the way you're building it. Hopefully I'll be quicker to realize that next time.
Bookmarks