I am trying to do something a little unusual… (don’t you love posts that start like that!)
I am creating a library which 3rd parties will use. They will link to the library statically. These people will not be using Juce necessarily. However, I would like to be able to create Juce Component derived objects by exporting static interface functions such as:
LibComp * myComp = createLIbComp(…);
The 3rd parties need to be able to add these objects as native child windows of their GUIS, move them and resize them, etc. I could force all of this to happen through interface functions in my LibComp class if necessary, although the holy grail would be for the 3rd party to be able to use native windows messaging. I see that I can use getWindowHandle to get the native window handle. Before I go and implement something based on using this, will the window handle returned by getWindowHandle actually be able to handle native messages to do things like setting a new parent and resizing or moving? If not, is there some other way to do this?
By the way, I will ensure that initialJuce_GUI() is called from within my library.
Not got much to offer in answer to your question, but you should perhaps bear in mind that there may be licensing issues with your end product. Not that it can’t work, but it may require additional precautions/steps in your distribution.
For example, if you are providing a closed-source, commercial library to people who are not otherwise using Juce, they may not expect to require a Juce license for their project. However, depending on the level of functionality you expose, Jules may consider usage of that library as tantamount to using Juce directly [and why should they not have to purchase a license for their use just because they’re going through someone else’s layer?]. As such, you may need to make it clear in your own license that they cannot release a closed source project using your library without also aquiring a suitable license from Jules.
Whether or not Jules considers any of that necessary is his decision, naturally! It would be prudent to allow him the right to inspect the nature of the library if you are planning to distribute it (even if you do have a Juce license yourself).
OK, that is a very good point. I will definitely consult Jules about that before this goes much further. It shouldn’t be a problem for me to publish the Juce component as open source if needed, but I will be sure to check it out.
Of course, if I can’t use Juce to do what my question was pointing towards, it’s a moot point!
From your description, it sounds like this’d be ok in terms of licensing. As long as these 3rd-party developers don’t actually compile or include any juce source code in their own projects, then it’d be fine. Of course, if they do need to include juce.h in order to use your LibComp classes, then they would need to buy their own commercial license (or make their own code GPL), same as anyone else who uses it, but it doesn’t sound like that’s your intention.
As far as exposing a HWND, yes, that should be easy enough - just use Component::addToDesktop and it’ll create a HWND that you can pass around. As long as they’re running a normal win32 event loop then it should all work, just like it does for plugin UIs.
Thanks for that - the juce code will be hidden away in my library, so the user won’t know what’s going on underneath the hood and will not have to include juce.h. So it sounds like I am OK on that front.
Also - thanks for that tip on addToDesktop. I tried it, and it works. Easy as pie.
