DLL and Juce GUI


#1

Hi all
I wish all of you a happy new year.

But, because of work never ends, I need your help on the following problem :
I am trying to put together a DLL with a client program accessing it.

  1. In the DLL :

I am creating a Juce-component which contains a few subcomponents.
At the Dllmain() function, I initialize the Juce-GUI.
After that, I am calling an DLL-exporting function from the client program, which is creating the DLL-Juce component and is returning to the client program a component* pointer.

  1. In the client program :

After the getComponent() function was returned, I use the addChildComponent(Comp) function to add the DLL-juce component to the client gui.
It seems to work as I can expected, until it mets the parentHierarchyChanged() function inside the Component::internalHierarchyChanged(). At this point I am getting an exception that the local this pointer contains an unexpected value (actualy the 0xfffffffffffe value).

I spent many hours but I did not understand where is the problem’s root.
Any help will be much apreciated.

Thanks in advance

George


#2

At the Dllmain() function, I initialize the Juce-GUI.
This sounds very wrong. You should never really do anything in the DllMain() function (you are in a locked dll-loading context from the OS), create a thread if you must. But…

Why are you initializing the JUCE GUI in a DLL?

Are your client program and your DLL linking against the same JUCE static lib? Probably not, you would have to go out of your way to make that happen.

So what probably happens is you have 2 JUCE libraries running in the same program, compiled under different contexts (and maybe with different flags, release/debug) which will inevitably go wrong.

The only way to do this is to factor JUCE into a separate DLL, and have your program and your DLL link against that, but even then it is sketchy. Note this stuff is only needed if you insist on using C++ across different contexts.


#3

I am initializing the JUCE gui in the DLL because the DLL contains some Juce gui components.
Before this initialization, I set the DLL module instance handler to the handler provited by the Dllmain (first parameter), which stands for the handler of the main client program.
I think so far this is the right way, after what I have read. Ok, now I already have a big doubt.

Anyway, I thing I have realize what is the main point explained in your post.
The point is to have one and only one copy of JUCE library running in a common heap for the DLL and the client program, right?
In this case, the only I need is to include only the Juce header-files when I implement either the DLLs and/or the client programs.
But, how can I do this using Projucer?
Probably I have to make a lot of hand-work to achieve this. .


#4

I‘d suggest to rethink your design. Crossing DLL boundaries with anything other than a C-style pointer or trivial numbers is asking for trouble especially when you want something as tightly coupled as the parent child relationship between JUCE components.

As soon as you deallocate something that was allocated on the other side, the program will crash and this happens pretty quickly (eg copy constructor of String => BAM)


#5

The point is to have one and only one copy of JUCE library running in a common heap for the DLL and the client program, right?

Yes.

In this case, the only I need is to include only the Juce header-files when I implement either the DLLs and/or the client programs.

Yes.

But, how can I do this using Projucer?
Probably I have to make a lot of hand-work to achieve this. .

That’s why I said you would have to go out of your way to make this work :slight_smile: Projucer makes monolithic programs, whether you create shared libs or programs, so I’m not even sure.


#6

Well,

  • I have read every single post in the juce-forum containing “DLL”, “JUCE_DLL” and any other similar keyword.
  • I built the Juce_dll static library located at “/extras/windows dll/jucedll.jucer” of Juce folder.
  • I created my Juce-project including only the juce-header’s files and the “juce_dll.lib” static library.
  • I spent many hours trying to make my project to work correctly.

Eventually, I did all of these for nothing. I am continuously getting dozens of LNK2038 and LNK2001 linking errors.
I am tending to believe that a project like that is not implementable at all.
Maybe, Ι have not realize enough the process of creating such a project.

If anyone can post here some clean tips or guidelines or a typical process about this issue, it will be much appreciated.

Othrwise, I will chose the most worst solution for my project : To put all toghether in a big/huge/monster .exe.

George


#7

Any suggestion on this ?


#8

Why don’t you just make a normal stand-alone app of your “client program” by adding the relevant juce modules to it? You haven’t explained why you need it to be a dll, only presented all problems in trying to make one.


#9

My basic implementation is consisted by the following:

  • A group of libraries (1–>n) that each of them contains a group of functions similar to each other (e.g. a group of audio filters).
  • A client program that is used to:
    • Shows the user a general catalogue of the contents of all libraries found in a specific folder, sorted by library.
    • Creates an instance for each specific sub-program the user selects from the general catalog of contents of the libraries.

So, if I need to add a new collection of sub-programs (e.g. a new collection of audio filters), the only thing I need to do is to create a new library and share it to my customers.

Otherwise, I will have to send a huge .exe program, every time I need to add just a small change or a new collection of sub-programs.

I think this, as I described above, is an important reason, that pushes me to spend a lot of time on it, before I leave the idea.


#10

Sounds to me as a blueprint for a daw with lots of plugins!

The first thing I would do in your case would be to see if your libraries could be designed as plugins. That would probably save a lot of work as it’s a well known concept, esp with Juce. If that’s not feasible, design your own interface with a common set of exported C-functions and package your libraries as dlls, with or without any juce code in them.

Design your client program as a Juce app (.exe). From this you load/scan your libraries/dll:s in a manner similar that a daw does with its plugins. There’s a lot of demos available for this amonth the juce examples code.