Compiling a dll (TEMPLATE =LIB) with MSVC2012 leads to unresolved external symbol

[maitai]

Thanks for your help,

So basically I need to have a shared library between my main application and the plugins...

Other solutions that crossed my mind:

Can I instead derived the classes I need from generic classes containing only pure virtual methods and use these generic classes in the plugins? In fact I need only 4 or 5 classes and around 30 methods from the main application, but if I need to build a shared library I'll probably need to put much more in it to since these classes are calling/using/instantiating many things...

Or maybe I can remove all these annoying classes from the plugins and use instead signals and slots to retrieve the information I need from the main app and also to trigger some action from it? For instance instead of doing object->getStatus() I would emit getObjectStatus() and get the reply in a slot... Sounds more complicated but maybe that would do the trick?

Thanks again

[d_stranz]

Can I instead derived the classes I need from generic classes containing only pure virtual methods and use these generic classes in the plugins?

In principle, possibly, but at some point you need to supply your DLL with concrete instances of classes derived from those pure virtual classes. Maybe you can do this with a signal / slot mechanism, but I think you are more likely to be successful if you build a static library (or non-plugin DLL) that is shared between the main app and the plugin DLL that contains the classes you want both of them to have access to. If you make it a non-plugin DLL that automatically gets loaded at startup, then you only need to link your plugin against the .LIB that MSVC builds for the DLL.

[maitai]

I have tested the idea of subclassing my main application classes with pure virtual classes, with a small example. That works wonderfully and I just need to declare in the virtual classes the methods I need. It works a bit like a reverse interface from the plugin to the main application. There is no reference to the real class in the plugin, it just uses the virtual one (just a .h file)

I will continue that way with the real stuff which is much more complicated than my small example and I'll keep you posted

Many thanks for your help

[d_stranz]

Yes, this will work. I presume that at some point in loading the plugin, you call some type of "initialize()" method and pass in a pointer to a concrete instance of the virtual class, right?

If you look at the Qt Creator architecture, the main application is pretty much just a plugin loader. All of the functionality of Creator is moved into plugin DLLs, one of which (Core) is required to be present. The other plugins ask Core to do things for them, through virtual interfaces. Your implementation basically merges Core aand the main app together.

[maitai]

Yes, this will work. I presume that at some point in loading the plugin, you call some type of "initialize()" method and pass in a pointer to a concrete instance of the virtual class, right?

Yes exactly. I load the plugin from my main widget (which is a MainWindow, derived from MainWindowInterface, itself derived from QMainWindow), and do something like
pluginLoader->instance()->init((MainWindowInterface *)this);

After that the plugin has a concrete instance of my widget, and can use whatever methods or even slots that are defined as virtual in MainWindowInterface.h. That way I don't need to link it against MainWindow's actual code.