DLL-ing a pure juce application (for plug-in purpose)

General JUCE discussion
1

hi agian. I afraid what i trie to do is not possible tha easy, but nevertheless, here i go.

i pack a class into a dll. i give the dll a function to retrive an object of that class. like this: (all is pure juce here)

class Module: privat Component{ Module(ModuleContainer*parent); ~Module(); ... ... } __declspec( dllexport ) Module* getAnObject(ModuleContainer*parent){ return new Module(parent); }

and in the Host i use Windows functions to load the dll manually(i wan tto make plug in architecture), the rest is pure juce code.

typedef Module* (*getModuleFromDLL_)(ModuleContainer* container);
Module* loadModule(){

	Module* newModule;
	HINSTANCE hinstLib; 
    BOOL fFreeResult, fRunTimeLinkSuccess = FALSE; 
	getModuleFromDLL_ moduleGetter; 
    
	hinstLib = LoadLibrary(TEXT("Module.dll")); 
 
    if (hinstLib != NULL)
    {
        moduleGetter = (getModuleFromDLL_) GetProcAddress(hinstLib, "getModuleFromDLL"); 
 
        if (NULL != moduleGetter) {
			newModule = moduleGetter(container);
        }
		else AlertWindow::showMessageBox(AlertWindow::WarningIcon,"cantgetProc","");
 
        fFreeResult = FreeLibrary(hinstLib); 
    } 
	else AlertWindow::showMessageBox(AlertWindow::WarningIcon,"cant load file","");
    if (! fRunTimeLinkSuccess) 
        printf("Message via alternative method\n"); */

	return newModule;
}[/code]

the loading of the dll and proc seems to work fine, but if i try to set the bounds of the retrived object i get an jassert that the loaded comp is in a different message loop, so its not thread safe to manipulate it from host.

[code]Module* newModule = loadModule(moduleType);
		const MessageManagerLock mmLock;//tested without too
		newModule->setBounds(x,y,100,50);// <-- jassert in this fiunction()

...
...

    // if component methods are being called from threads other than the message
    // thread, you'll need to use a MessageManagerLock object to make sure it's thread-safe.

i end here :frowning:

is there a way around? is this because the dll must spawn another thread/process?
i called initialiseJuce_GUI ( ) after getting the “juce not initialised” jasserts in the dllmain() and such (i copied the whole main from vstWrapper), and after i’ve seen this is nessecary it was almost clear that the class gets not just loaded, no, it creates a whole new process.
(i’m totally new to dll, actualy my first step, so please bear with me if i say something dump).

so can’t i just append the comp to the other comps (as i child, like it is a class like the one linked at compile time) and the main message loop? can i make the calls using a MessageManagerLock (seemed not to work, and would be tedious)?

please say there is an easy solution, from what i’ve read now it seems like there isn’t such a thing.

thanks in advance

D3CK

2

Jeez, if you’re new to dlls you’re setting yourself up for a lot of hassle! It’s possible but not easy. You’ll need to make sure the app and DLLs are all compiled with exactly the same version of juce though, and will both have to use the juce DLL rather than the static lib. I’ve no time to help you with all the many pitfalls, but check out the plugin wrapper code for tips, because obviously that runs in a DLL (although it doesn’t attempt to share objects across DLL boundaries).

3

ok, i’ll try linking to juce at runtime and see how far i get. mmhh. everytime the same juce version may complicate for third party devs (i mean my project will stay open source most likely), but its better to have module as a bunch of files in a folder then having to compile them into the host. i think once set up this is the easyer way to manage modules. hownever. maybe i’ll ditch all this.

thanks for the little help again.

peace

D3CK

4

If you’re trying to have 3rd party plugins, really the only way is to do it like audio plugins - don’t pass any shared objects across at all - just have a very small, clearly defined API and give the plugin a window to draw in.

5

yeah thought of tha myself :wink: . the code i’m working on is GUI and Functionality mixed, so there is a disign flaw too i guess.

thanks jules.

D3CK