My environment is wxWidgets 2.9.5, MSW 8.1, mingw, CodeLite.
I am trying to modularise my application and would like to include wxPDFDocument in my own DLL (lets call it myCoreDLL) along with a few other core classes. I can build this DLL fine, following the instructions posted here http://forums.wxwidgets.org/viewtopic.php?f=30&t=29473 (at the entry where it is marked solved).
The problem is that when I try to use wxPDFDocument (embedded in myCoreDLL) from my main application I run into problems because the header file wxpdfdoc.h wants to pull in several other header files from a subdirectory of the myCoreDLL source tree (which is not in the include path).
Is there another header file designed for this purpose that I have missed?
Many thanks
Using wxPDFDocument in a library Topic is solved
Using wxPDFDocument in a library
wxWidgets 3.1.2, MinGW64 8.1.0, g++ 8.1.0, Ubuntu 19.04, Windows 10, CodeLite + wxCrafter
Some people, when confronted with a GUI problem, think "I know, I'll use Eclipse RCP". Now they have two problems.
Some people, when confronted with a GUI problem, think "I know, I'll use Eclipse RCP". Now they have two problems.
Re: Using wxPDFDocument in a library
So why don't you just add the relevant subdirectory (where the wxPdfDocument related header files reside) to the include path of your main application? It's not uncommon that a header file depends on other header files.iwbnwif wrote:I am trying to modularise my application and would like to include wxPDFDocument in my own DLL (lets call it myCoreDLL) along with a few other core classes. I can build this DLL fine, following the instructions posted here http://forums.wxwidgets.org/viewtopic.php?f=30&t=29473 (at the entry where it is marked solved).
The problem is that when I try to use wxPDFDocument (embedded in myCoreDLL) from my main application I run into problems because the header file wxpdfdoc.h wants to pull in several other header files from a subdirectory of the myCoreDLL source tree (which is not in the include path).
Simple answer: No. If you want to hide the wxPdfDocument dependency you have to introduce your own facade class (residing in myCoreDLL and having a single header file) similar to the following code fragment:iwbnwif wrote:Is there another header file designed for this purpose that I have missed?
Code: Select all
class wxPdfDocument; // No header file required for this forward declaration
class PdfDocumentFacade
{
public:
// Put here all methods required in your main application
// ...
private:
wxPdfDocument* m_pdfDocument;
};
Ulrich
Re: Using wxPDFDocument in a library
Thank you for such a fast reply!
I think your facade example will do exactly what I want, however did you mean that I should inherit the facade from wxPdfDocument, i.e. something like
If I try this then I get compiler errors (mingw gcc) for invalid use of incomplete type 'class wxPdfDocument' and forward declaration of 'class wxPdfDocument'
Yes, I can do this, I just thought it would be tidier to have just one .h.So why don't you just add the relevant subdirectory (where the wxPdfDocument related header files reside) to the include path of your main application?
I think your facade example will do exactly what I want, however did you mean that I should inherit the facade from wxPdfDocument, i.e. something like
Code: Select all
class wxPdfDocument; // No header file required for this forward declaration
class PdfDocumentFacade : public wxPdfDocument
{
public:
// Put here all methods required in your main application
// ...
private:
wxPdfDocument* m_pdfDocument;
};
wxWidgets 3.1.2, MinGW64 8.1.0, g++ 8.1.0, Ubuntu 19.04, Windows 10, CodeLite + wxCrafter
Some people, when confronted with a GUI problem, think "I know, I'll use Eclipse RCP". Now they have two problems.
Some people, when confronted with a GUI problem, think "I know, I'll use Eclipse RCP". Now they have two problems.
Re: Using wxPDFDocument in a library
Well, the wxPdfDocument headers could possibly be redesigned to reduce dependencies. However, you will almost always need to include more than one header file when using wxPdfDocument. Therefore you should either add the path to wxPdfDocument to the include path of your main application or encapsulate the use of wxPdfDocument in your own class.iwbnwif wrote:Yes, I can do this, I just thought it would be tidier to have just one .h.So why don't you just add the relevant subdirectory (where the wxPdfDocument related header files reside) to the include path of your main application?
As you observed yourself, inheriting from wxPdfDocument doesn't solve your problem. For inheriting the compiler needs to know the full specification of the super class. That is, you would have to include "pdfdocument.h".iwbnwif wrote:I think your facade example will do exactly what I want, however did you mean that I should inherit the facade from wxPdfDocument, i.e. something like
If I try this then I get compiler errors (mingw gcc) for invalid use of incomplete type 'class wxPdfDocument' and forward declaration of 'class wxPdfDocument'Code: Select all
class wxPdfDocument; // No header file required for this forward declaration class PdfDocumentFacade : public wxPdfDocument { public: // Put here all methods required in your main application // ... private: wxPdfDocument* m_pdfDocument; };
Using the facade pattern is the only way to avoid to have to include "pdfdocument.h" (and all of its dependencies). That is, as in my code fragment you have only a pointer to a wxPdfDocument instance and you have to declare methods for all operations you want to perform on that wxPdfDocument instance.
It's difficult to tell whether this is worth the effort for just removing the header file dependency. Personally I would probably add the path to wxPdfDocument to the include path. However, it depends on the type of application you are building.
Regards,
Ulrich
Re: Using wxPDFDocument in a library
Thank you for the clear and detailed response.
For now I will probably take the simple route and have the path to the include files available for both the application and the plugin projects.
For now I will probably take the simple route and have the path to the include files available for both the application and the plugin projects.
wxWidgets 3.1.2, MinGW64 8.1.0, g++ 8.1.0, Ubuntu 19.04, Windows 10, CodeLite + wxCrafter
Some people, when confronted with a GUI problem, think "I know, I'll use Eclipse RCP". Now they have two problems.
Some people, when confronted with a GUI problem, think "I know, I'll use Eclipse RCP". Now they have two problems.