Re: getting a com interface from an out of process erver
Drew Hohmann <drew@med-associates.com> wrote:
I am creating an instance of an object, then one of the methods of the
object will return an instance to a different object (similar to how
the windows media player com interface works, see
IWMReaderAccelerator::GetCodecInterface for an example).
Note that IWMReaderAccelerator is not automation-compatible.
In process this works fine, but out of process it appears that neither
the IID or the pointer are being marshaled correctly. I did notice
that according to the oleautomation attribute documentation, GUID's
are not one of the types listed as automation compatible (nor are
variants?!?!?).
VARIANTs are automation compatible. GUIDs are not. Most automation
clients only know how to use IDispatch anyway, and have no need for
IIDs.
I'd be willing to give up the guid, as long as I
could get the IUnknown ** to work.
IUnknown should work. You must be doing something wrong.
//idl code
[
object,
uuid(3BB9B8DD-3060-42D3-8F7E-3F1BE464B031),
oleautomation,
dual,
nonextensible,
helpstring("IT1 Interface"),
pointer_default(unique)
]
interface IT1 : IDispatch{
[id(1), helpstring("method GetTClass")] HRESULT GetTClass([in]
REFIID riid, [out] IUnknown** tclass);
This is certainly not an automation-compatible method, and won't marshal
correctly using TLB-driven marshalling.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925