Adam Lock wrote: > > I am mulling over options for adding scripting to my plugin for hosting > ActiveX controls, so that JS can make calls directly onto methods on the > hosted control. > > I want to be able to dynamically read the control's COM interface from > it's typelib and expose an equivalent interface in XPCOM. > > Is this feasible? > > I believe I can implement an object derived from the XPC stub class that > could marshal the interface calls back and forth but is it possible > generate the appropriate XPT at runtime for this interface? By this I > mean, can I build the XPT in memory and register them without copying > .xpt files into components/?
Adam, Sorry to be so slow to reply... Sounds like two problems: 1) Making the typeinfo available. The existing typelib loader (xpti) is very much oriented toward reading the xpt files from the disk. I don't support the idea of hacking it to do otherwise. However, we are facing a similar problem for reflecting WSDL based SOAP services as xpcom interfaces. The strategy we are pursuing is to have a concept of 'additional' type info managers. The one true manager will support maintaining a list of weak references to additional implmentors of the nsIInterafaceInfoManager interface. These will be created dynamically to reflect the interfaces of particular web service providers. XPConnect will be modified to ask the managers in this list when looking for interface infos that are not available from the 'real' manager. We plan to use this only for interfaces that will not be implemented by real C++ objects; i.e. we will use this generated info to help us in calling from script code into xpc stub based code that is itself based on this info. This leaves no danger of a mismatch between the info and some concrete class causing a crash. You could leverage this scheme. I have an untested impl of the core xpti changes in bug 103805. XPConnect changes would still need to be made. Vidur wrote a semi-generic chunk of code for interface infos in extensions\xmlextras\wsdl\src. It is not clear that we are going to use what he did in its present form. But it is a starting point for code you might use. 2) Reflecting the objects into JS. It seems to me that you could just use xpconnect for this. If you are talking about direct calls to IUnknown based interfaces where the param data types match xpcom data types then xpconnect should just work. Assuming that xpconnect has been modified to find the dynamically generated type info, you'd just need to ask xpconnect (using nsIXPConnect::WrapNative) to build wrappers around the objects for the given iids. Unless you are transparently mapping to IDispatch calls or something I would expect this strategy to work. John.
