2012/5/14 Michael Jackson <imikejack...@gmail.com>: >> ... >> Could it be that it needs to be: >> >> PipelineBuilderLib_EXPORT class WFilterWidget : public ... >> >> instead? >> ... > Putting "PipelineBuilderLib_EXPORT" before the "class" keyword just results > in a bunch of compiler warnings
Ah sorry, my wrong: http://msdn.microsoft.com/en-us/library/a90k134d%28v=vs.80%29.aspx I usually define a simple *.h. For instance if my DLL was called Foo I would have FooLib.h with simply: #ifndef FOOLIB_H #define FOOLIB_H #include <QtCore/QtGlobal> #ifdef FOO_EXPORT # define FOO_API Q_DECL_EXPORT #else # define FOO_API Q_DECL_IMPORT #endif #endif Note the usage of Q_DECL_EXPORT|IMPORT (defined in <QtCore/QtGlobal>) which automagically gets rendered as this MSVC-specific __declspec-stuff, and to appropriate "export" declarations (or mostly "nothing") everywhere else (so not sure whether it gets rendered as __attribute__ ((visibility("default"))) on Linux, but we'll leave that away for now for simplicity). In the actual implementation header Foo.h: #include "FooLib.h" class FOO_API Foo : public QObject { Q_OBJECT public: ... }; I prefer: class Foo : public QObject { Q_OBJECT public: FOO_API Foo(); // c'tor FOO_API virtual ~Foo(); FOO_API void exportedMethod(); void notVisibleOutsideOfDLL(); signal: void someSignalWhichCanAlsoBeConnectedFromOutsideOfThisDLL(); protected: FOO_API void canBeOverwrittenWithClassesInOtherLibraries(); void canOnlyBeOverwrittenInThisLibrary(); ... }; Off course you then define FOO_EXPORT when you build the DLL, but DON'T define it when building everything else. This works cross-platform, including to connecting the above signal to some slot in another library/executable ("signals across DLL boundaries"). Cheers, Oliver _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
