This isn't a bug. It is simply a difference in the method of implementation.
If your QWidget-derived class uses a UI file that declares a class containing the UIC-generated UI class (in your case DialogTest, which is scoped to the Ui namespace), there are three ways to add that to the QWidget class that uses it.
First is the way your QDialog-derived DialogTest class uses it: as a pointer member of DialogTest. In this case, all you need is a forward declaration of the pointer class (Ui:: DialogTest). This is what QtCreator does.
The second way is to include Ui:: DialogClass as a member variable (not a pointer) in the DialogTest Class.
The third way is to use multiple inheritance and derive DialogTest from both QDialog and Ui:: DialogTest.
To implement these last two cases, the compiler must have access to the full definition of the Ui:: DialogTest class. This requires a #include of the ui_dialogtest.h file. A forward reference is not sufficient.
The Visual Studio plugin simply covers all cases by by #including the ui header file no matter how you use the Ui class. It isn't a bug, but it assumes that all of the code that uses the class has access to the Ui header file. This is the most common use case. It only breaks down in the rare case where the Ui class is part of a DLL -and- the QWidget-based class uses the pointer to Ui member idiom. In that case, all you have to do is move the #include statement from the .h file to the .cpp file as you have done, and replace it with a forward declaration in the header file. No big deal.
By the way if you have other resources in a DLL that you want to use in an EXE (icons, bitmaps, etc.), then you add this declaration (in main.cpp) :
int main( int argc, char * argv[] )
{
Q_INIT_RESOURCE( MyDLL );
// ...
}
int main( int argc, char * argv[] )
{
QApplication a( argc, argv );
Q_INIT_RESOURCE( MyDLL );
// ...
}
To copy to clipboard, switch view to plain text mode
assuming your DLL is named MyDLL.dll.
Bookmarks