Promoting widgets in QT5 (VS2010, Windows) results in "C1083: Cannot open include file: 'mywidget.h': No such file or directory"
I'm new to QT (and I hope this is the right place to ask) but I know enough to know that one project I would like to complete will require promotion of a widget to its own class.
I've been doing this by adding a new QT Designer Form Class to my project, then promoting the widget to that class - for example, MyWidget. This causes the line:
to be added to ui_mainwindow.h, which causes the build process to bork because it can't find the file:
bq. C1083: Cannot open include file: ‘mywidget.h’: No such file or directory
If I manually change it to
Then it works (because ui_mainwindow.h is created by default in a sibling folder ("myproject-build-Desktop_Qt_5_0_0_MSVC2010_32bit_SDK-Debug") of myproject) but ui_mainwindow.h gets rebuilt every time I change my UI, so I have to continually alter this line to get my project to build.
Am I doing something wrong? Is this a VS2010 problem rather than a QT problem? This single promoted widget is the only thing in my project, and I haven't altered any other code from the initial blank project.
When you're defining a promoted widget in designer there's a place to put "header file". Put there the right include path, not just "mywidget.h". Also mywidget sounds like your own class so you should probably use "mywidget.h" instead of <mywidget.h> (uncheck "global include" in the dialog).
Thanks, that worked.
It seems a poor way of having to do things, though - being required to specify a full path to a file which is already part of my project, and having to do so by manually typing the path instead of being offered a file dialog. Still, the problem is solved - thanks!
Glad to hear the problem is solved.
On the path selecting note: think about it a little deeper. The path you put there is stored in the .ui file. If you just specified "mywidget.h" and had several such files in different subdirectories (which is more than common) -which should be chosen and basing on what premise? And the dialog - dialog returns an absolute path to the file and you certainly wouldn't want that. If it were to be made relative automaticallly the problem rises again - relative to what? certainly not the .pro file since one .ui can be part of different .pro files in different locations or in certain situations there is no .pro file at all. Certainly not relative to the .ui file either since those can be moved around and uic'ed or even loaded dynamically so the path would be broken in some situations.
So the choice is left to you, the programmer - if you want to keep it relative to something you can do it, if you want to hardcode the full path you can do it, if you want it to be set to some system environment variable you can do it etc.
If you really don't like those answers you could try to add a INCLUDEPATH += "path where mywidget.h resides" to your .pro file, this would basically treat this path as yet another "base" directory so you could write just "widget.h"
Ah, I see - I hadn't considered these more complicated scenarios. Thanks for the INCLUDEPATH tip, too - I think this sounds like the best fit for my programming style.