Request: heavyweight empty childwindow component


#1

Hi, Jules,

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.


#2

+1


#3

+1


#4

Yes - it’s a good request. As there’s already a similar component on the mac, a windows one would be a nice addition, especially if I can design something that would also work as the base for the other existing heavyweight components.


#5

+1.

I’m fast realizing that trying to get VTK to draw onto a JUCE OpenGLComponent through a shared lib, on all three platforms is a bit beyond me.

A nice container HWComponent that I could just point at say “OK, there’s your viewport, so get on with it,” would suit me down to the ground! :slight_smile:

From what I’ve seen of a few different libraries that support hooking into an existing UI, on Windows and Linux, you typically only need to pass the view, whereas on OSX you need to pass the window and view.


#6

adding a +1… i really want to get our internal library code running in a juce component to simplify making editors, etc…, but it’s proving to be a massive pain in the arse. A base heavyweight window class would be a ‘proper treat’.

+1000000000000000000000


#7

It’s already there! It’s not very well publicised, but do a search for NSViewComponent…


#8

but that’s mac only, right?


#9

Oh yes, sorry… Have just got back from a festival, a little bit tired and speed-reading all the weekend’s posts!


#10

+1
in our project we need to show many activeX objects within a JUCE form or a JUCE component, so having such a container would be really helpfull for us…


#11

Good idea.It will make JUCE more powerful.
Does this useful component implement in the latest version?
I am a new here,please forgive my poor English. :stuck_out_tongue: