unable to find header file referenced from ui_widget.h
-
@Colins2 said in unable to find header file referenced from ui_widget.h:
That's what I thought, there is no actual code/compiler error.
Ohhh! So this is only the code helper in the editor? Then you don't have a real problem.
But earlier you said:
I get an error that cannot find file "indicator.h" referenced in ui_widget.h and the compilation stops
That is during compilation after all? can you please be 100% clear about whether you have (a) an editor-only warning message inside the IDE or (b) a genuine error from running the compiler?
If it's IDE code model only, I think that sometimes gets itself wrong. You could try cleaning everything out --- any cached files?
.pro.user
, I don't know?) and/or seeing whether it sorts itself out over time....Ah, now I think I understand:
- You get an editor "no file" on
btestwidget.h
. - You get a compiler "no file" on
atestwidget.h
I only trust compiler messages! Sort that out first, before confusing it with whatever the editor warnings are saying. Your
ui_widget.h
is not going to be in same directory as*testwidget.h
is it?ui_....h
file is generated into build output directory (for debug or release). Not sure what compiler options tell it to look back in source directory to file.h
files.That's all I know, obviously I don't know your exact situation.
- You get an editor "no file" on
-
@JonB
I guess I didn't explain it too well.
Yes, the ui_widget.h file is in the build directory, where you would expect.
The original post showed the error on btestwidget as I had already deleted atestwidget to test my theory.The 2nd code I re-created the gui with the 3 widgets and promoted them and, as you can see, it is now the atestwidget that gets ignored. If I delete both atestwidget and btestwidget then ctestwidget gets ignored, i.e. the first entry.
Something isn't right.
I would mention that all the code in this test application, apart from the names and the creation of the objects, is generated by Qt.
There is no other code anywhere. -
@Colins2
I think what you are saying about "first, second, third" widget and "gets ignored" is a red herring. I suspect you simply only get an error on the first problem it encounters, they all have the same issue but you just don't get subsequent errors about the other ones?Simplify your situation to a single promoted class, get that working, then try multiple promotes.
I suspect an old post like https://stackoverflow.com/questions/4907766/promoting-widgets-in-qt-creator I came across is linked to your issue? First ensure you have added to
HEADERS
like it says. Then try to figure how wherever theui_....h
file is it will know to findatestwidget.h
which is in your "source" directory? Maybe play with.pro
file'sINCLUDEPATH
so it has the absolute path to prove that can make it work, then figure what you're really supposed to do after that?If it's all different because you are using cmake that is beyond my ken. Maybe something like https://stackoverflow.com/questions/24222057/error-for-compiling-qt-gui-with-cmake-along-with-promoted-widget is saying you need to do something to get cmake stuff/compilatuon look in the source directory? Maybe Googling
qt promote widget cmake
provides some useful links?That's all I know. Another person here may know more about this Promoting issue.
-
@JonB
Yes, you were right about the file getting ignored. It stops compliation on the first header that it can't find.
So that clears that point up - doesn't help me but it's one less thing to worry about.
None of the promoted classes will work but when demoted back to QWidgets, they work fine.I'll check those other links but I thought I'd try here first to see if anyone else had come across the problem.
Thanks for your input. -
Please provide a minimal, compilable example - not three widgets and a lot of unneeded stuff... you most likely don't link against the library where your widgets are in or don't properly specify the target_include_directories() for this/those libraries. If I'm right it has nothing to do with promoting widgets but simply on how to link against a library with cmake and specific the correct include paths for this library.
-
@Christian-Ehrlicher
Thanks for your reply.
The 3 widgets were necessary, I thought, to emphasize the point but as JonB pointed out, it fails on the first error, no matter how many widgets are promoted.
It has nothing to do with libraries or include directories, this is just basic stuff almost entirely generated by QtCreator.
The solution is to put the FULL path of the include file in the promote box and then it works. It should not be necessary but obviously one of the compilers, UIC maybe, doesn't read the CMakeLists.txt file to find where the files are, at least on Linux.
The instructor on the course I am following does not do this, he simply leaves the generated header file name in the box but I think he is using Windows. I will also put this to him and see what his response is.
This does appear to have been a problem for more than 10 years, reading stackoverflow but I'll mark it as solved now as this workaround works. -
@Colins2 said in unable to find header file referenced from ui_widget.h:
The solution is to put the FULL path of the include file in the promote box and then it works. It should not be necessary but obviously one of the compilers, UIC maybe, doesn't read the CMakeLists.txt file to find where the files are, at least on Linux.
This is plain wrong- it has to do with the correct target_include_directories() calls.
-
@Colins2 said in unable to find header file referenced from ui_widget.h:
The solution is to put the FULL path of the include file in the promote box and then it works
As @Christian-Ehrlicher says. I suggested you test whether that would make the compilation work, so that we could confirm that was the issue. The https://stackoverflow.com/questions/24222057/error-for-compiling-qt-gui-with-cmake-along-with-promoted-widget I referenced offers:
include_directories(${CMAKE_CURRENT_SOURCE_DIR}) include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include) include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include/jir_seg)
or @Christian-Ehrlicher's
target_include_directories
, something like that looks preferable. -
@Christian-Ehrlicher
I will gladly try another approach.
Following advice on stackoverflow from many years ago I added
include_directories (${PROJECT_SOURCE_DIR}) to my CMakeLists.txt file and that worked. With all the other automatic or templated functions that happen without any user input, I find it strange to have to add this manually.
There used to be a template file where you could set default values for CMakeLists like CXX_STANDARD etc. Where is that file now, I can't find one anywhere? -
@Colins2 said in unable to find header file referenced from ui_widget.h:
There used to be a template file where you could set default values for CMakeLists like CXX_STANDARD etc. Where is that file now, I can't find one anywhere?
There is no such a file.
If you want to add an include path you hjave to use target_include_directories (include_directories should be avoided) - but that's also true for qmake.
-
@Christian-Ehrlicher
All working now, thanks for your help.
This is the first time I have ever had to use this command in Qt. Previously I've only used the target_link_libraries command with all source files and header files found from the automatically created ${PROJECT_SOURCES}.
I guess it would be good practise to always add this line in future projects. -
@Colins2 said in unable to find header file referenced from ui_widget.h:
This is the first time I have ever had to use this command in Qt
I think the difference is: In normal circumstances the
ui_....h
file, generated into the build output directory, has no#include "yourfile.h"
lines in it, as it is standalone and does not reference any of your source headers. So it does not need to know where your source directory is. However, because you used a Promoted widget, generated into the source directory, it does need to#include "atestwidget.h"
for the definition of the promoted widget it contains. So that is why it needs the path to that directory in this situation, but maybe not other cases.