I’ve asked similar questions before on this forum. (See http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=3210&highlight=create+heavy+window and http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=3211&highlight=create+heavy+window )
And I still think it will be a very useful feature. I would like to make the request more clear.
There are several heavyweight component in JUCE, including the ActivexComponent, OpenglComponent and maybe the quicktimecomponent. Interestingly , I just found the shadowed borders around the main window are
also heavyweighted although I cannot get the handles of them using spy++. (It seems the mouse event is filtered.) These heavyweighted windows are created using the native window creation command, such as createwindowex on win32. So they are the normal windows or childwindows which have handles.
one possible use of these native windows is to incorporate other libraries or user codes with JUCE. For example, many other graphic libraries like Orge3D and Irrlicht support using external window to create working environment. Some of those libraries are extremely powerful in 2D/3D, which implies one can hardly write such powerful codes by oneself. For instance, in JUCE forum I have seen somebody asked how to draw fonts or transparent texts or whatever else overlaying stuffs, or even a nice 2D gui in 3D opengl window.(Most of the proposed solution on this forum is to using off-screen render-to-image technique which is not ideal and has potential performance drawbacks.) Actually it is quite easy to be achieved using those libraries and more importantly the quality is assured. On the JUCE side it’s also as simple as just exposing a native window handle.
I’ve tried to do so by using the available heavyweighted JUCE components. As I mentioned in the other posts. The activex component needs a really controlID in order to creaet a native window. And the openglcomponent encapsulates some opengl codes and does not expose its handle directly. But these ‘decorated’ windows is not suitable to be used with other libraries, because normally the libraries need merely the ‘raw’ window handle. (I managed to find out the handle of OpenglCompoent by enumerating the heavyweight componentpeers, but I failed to use its handle with Irrlicht. I think the reason is the window styleflags are not compatible. Irrlicht has a nice example to use existing Childwindow as rendering target. see http://irrlicht.sourceforge.net/docu/example014.html . Not surprisingly it can also render on a normal button control. )
Back to the topic, I think it will be nice if JUCE could provide a native window component with overridable styles and parameters. It exposes the native window handle or other useful info. such as wndclassname or something alike. This leaves the users large freedom to incorporate other stuffs. (I know one can easily create a native window by himself and attach it as a child to the main window, but it’s tedious and you have to manage the position and zorder by yourself. So it could be better if it’s done within the JUCE framework. Think of the situ. before the birth of Openglcompoent, people could create an GL window using other toolkits but to manage this external window with the JUCE gui is not a pleasure. Plus this is a snap for JUCE IMO.) The last reason is I’m not familiar with all the platforms such as MAC, considering of the cross-platform ability of the program it’s better to implement this feature in JUCE.
Jules, do you think it’s reasonable to add such a component? Correct me if I’m wrong.