Hello mike,
I've thought about this before. The primary problem is that you'd need some custom IPC mechanism, as simply instantiating an ActiveX control and embedding it in a window isn't terribly useful, you generally want to call its methods and set its properties.
Yes, and for this I have a done something, see attach. (I have to test the properties and methods access)
I've pondered using DBUS for that. A simple DBUS<->COM bridge would be handy, though COM doesn't really map to DBUS very well, so it wouldn't be quite the same as using normal COM/DCOM.
if I make DBUS bridge with my attach will be not efficient?
I already put some basic support for processing XEMBED messages into Wine with my system tray patch, that isn't merged yet. You might want to take a look at that first.
I have patched your work in my wine src, it works very well :). But for the moment, it's too abstract. I don't understand how to simulate a GtkSocket creation, how to send the windows handle to another process window??? This part is very strange, like magical, hahaha. but maybe I just need to send the same messages as Gtksocket to GtkPlug?
The ATL is a C++ toolkit, beyond that I know little about it. The
easiest way to embed an ActiveX control is to turn a program into a WineLib app. At that point the problem becomes one of internally using XEMBED to synchronize the Wine toolkit and GTK. That sort of thing shouldn't be very hard, I expect a simple Wine extension to Win32 would work here (setting an extended window style or something).
For my tests I try all in wine application (embed activex and to use methods). After this, I will work for the magical xembed mechanism and at the end I will implement DBUS bridge.
thank you very much for your help. Olivier
------------------ www.programmers.ch