Reside a component in an existing window in a host app

#1

Before attempting to use JUCE, I have a small question, is it possible to place a JUCE Component inside a window which
has been created by another application, E.g. Omnis, or SuperCard (HyperCard) and patch in the event loop as this
is handled by the host application ??? From what I have seen so far the NativeDesktopWindow creates a new window,
but it should make use of the existing window presented by the host-application, and because that application has it’s
own GUI elements in the window, it should “share” the event loop with the host-app.

Is this possible at all ??

#2

Let’s compare with MFC. Juce can now be setup to use MFC’s event loop, so that’s a non-issue. MFC however uses CObject for everything, if something is going to be drawn inside an MFC window, it has to be derived from CObject (well technically something else, but still…). To draw a JUCE component inside an MFC window, you’d have to hook the window, and do post drawing, by far not an easy task. Theoretically you could make a CObject that used a JUCE Component and do a lot of mapping, would slow it down however, not be much, but could be noticable on slower systems. You can, however, create an entirely new window within the same applicatino that is controlled by JUCE…

#3

OvermindDL1,

Thanks for your reply, but my question was more Mac OSX related than Windows. But anyway I get your point. Would it be an idea to adjust the behaviour of the NativeDesktopWindow class to accept a window pointer, and use this instead of creating a new window, and of course if this pointer is NULL use the current behavior. But that still leaves the problem of having the host application feed events to JUCE. Or is there some meganism where the default event handlers of JUCE can send the event back to the event chain when JUCE does not handle the event??

#4

Similier context on Mac OSX…

#5

OvermindDL1,

I regret to say this is not the case, when a component is put into a window which is hosted by another application, you can not simply use the method of installing event handlers in the window. The events are send from the hostapplication by means of a callback, a bit like the VST demo in JUCE but more complex. Furthermore there can be multiple instances of the same component in the same window. All sharing the host application window as “main root”. The events will be send from the host application to the Juce Component based on which area has focus (which is also determined by the host application). So my question remains, is there a way to overrule the NativeDesktopWindow class concept so events can be inserted “Manually” and the component will accept the hast application as it’s root, and maybe share it with some other components ? Basically this has nothing to do with MFC or the Cocoa/Carbon event loop because the events are broadcasted to the area by the host application. The VST demo will not work, because it assumes it has the window for itself, this is not so in my case, because GUI elements from the host appliucation itself reside in the window as well as multiple instances of (maybe) a juce component.

#6

Well you can certainly embed a juce window in another app and use the app’s event loop. What you can’t do is take a window created by another app and make juce use it directly (it’d be possible to attach its event handlers to another window, but the two apps would be competing to draw onto it and to respond to events). I think that’s what you’re asking - let me know if I’ve misunderstood.

#7

Jules,

The host application sends a separate event to the area to redraw itself, so this could be used to give JUCE the opportunity to redraw itself. From what I have found out so far, one needs to create a new kind of NativeDesktopWindow class, e.g. NativeArea. And create routines to mimic the RepaintCombiner and inject the events from the host application. The problem with creating a JUCE window and grouping this with the host application window is that the JUCE window will “eat” all event’s. And thus making the whole thing useless. I had high hopes after looking at the JUCE demo, but it seems that the base structure of JUCE has to be rewritten completely to handle the required behavior as a separate area within a host window. Especially to be able to handle multiple separate Components in one host window.

Maybe you have tried this yourself, or have some suggestions ?? I would be willing to spend some additional time on it, but for now I’m a little stuck, other than start to rewrite the basic stuff myself…

Many thanks for your time and suggestions !!

#8

Don’t see why the juce window would eat any other events… surely on the mac all events handlers will get called regardless of each other - it’s not possible to take away events from another handler, is it?

Can’t think of any sensible way of doing it other than grouping a window with the app window - the idea of having areas sounds like a nightmare to make work…

#9

[quote=“jules”]Don’t see why the juce window would eat any other events… surely on the mac all events handlers will get called regardless of each other - it’s not possible to take away events from another handler, is it?
[/quote]

When a JUCE window is grouped to a window in the host application, all events outside the JUCE window are no longer sent to the host application, also any key-presses are no longer sent to the host application.

[quote=“jules”]
Can’t think of any sensible way of doing it other than grouping a window with the app window - the idea of having areas sounds like a nightmare to make work…[/quote]

It’s not a real nightmare, all applications supporting plugin area’s like RealBasic, Omnis, SuperCard, Hypercard make use of the philosophy. I was merely looking for a friendly cross platform framework for this task. And looking at Juce made me very enthusiastic at first, but I think I have to look further, anyway thanks for all the answers so far. And as said JUCE looks very attractive, and at a FAIR price !, just not meant for the things I need to create.

#10