I have a Windows GUI application that’s using the Qt framework (currently version 3.3.5, might change to Qt4).
I want to combine other Windows GUI applications in the main application. I can’t use the widgets directly in the main application due to several constrains which I can’t control. The final layout should look like this:
Currently I’m using the method outlined in a Hosting .exe applications into a dialog. In order to pass the HWND of the child applications I’m using my own IPC between the processes. Then, I need to forward resize events using Qt resizeEvent that calls ::MoveWindow on the child windows.
Is there a better or more generic mechanism for doing this? Some suggested that I use ActiveX, but I’m not familiar enough with this technology.
Here is how some Windows applications deal with this problem:
If the widget application must be in it’s own EXE, then you could use OLE document object embedding (I think that’s the right term). This is the same technology that is used to embed a live Excel document into a Word document. Basically, WMF-like data is used across processes to render the UI. This requires tons of work in both the host and widget programs unless the frameworks you’re building on top of support this automatically. MFC did a nice job with this… (man, did I just compliment MFC??)
A better solution would be to use some type of in-process solution. Have all the widgets be DLLs. This is how ActiveX works. If widgets needed to run out of process, split the rendering and the out-of-process stuff into 2 parts. An EXE that does the out-of-process stuff and do the rendering locally in the hosting processes. Use some type of IPC to glue them together.
I suspect that the ‘restrictions you can’t control’ are going to make nearly any ‘sane’ implementation impossible…