First thing you have to learn about COM is: COM is not C++. COM world knows nothing about C++ structures. COM knows nothing about any language specific constructs. COM knows only about COM.
The only generic way to pass some structured data via COM interfaces is passing COM objects.
There is a way to pass language specific types, though with limited support, and the way is called special marshaling. But as far as I know, IDispatch is intended to operate with universal marshaling compliant types, and the easiest way is again passing COM object's dispinterface.
Bottom line: you have to turn your C++ structure to a real COM object prior to letting it to COM world.
The only generic way to pass some structured data via COM interfaces is passing COM objects.
No, that's an incorrect view of things...
COM is about interfaces (functions) and you don't know what the "inside" (data) of a COM interface really is. Although it does happen, it's rare to see COM interfaces where you pass one COM 'object' into another COM 'object'. technically speaking 'COM object' isn't a right terminology, it's an instance of a COM interface.
passing data to/from COM interfaces is about using "agreed upon" data formats.
Generically this means you have:
- the elementary types like an BYTE, SHORT, INT, LONG, DATE...
- The string type BSTR
- The VARIANT
- The SAFEARRAY
Non-generically, you can technically use "any type" you want, including (pointers to) C++ structures and even C++ classes, but that means that particular member function will probably not be accessible/callable from anything but C++ or at least from any language that doesn't provide for specific memory organized data layouts.
In extreme cases, the presense of such memberfunctions might make the whole interface invalid on some platforms/languages. Part of the point of COM is about making some interface that is accessible for "any language", so using such constructs while possible, kind of makes you wonder why you went to COM in the first place if it's only accessible from C++
IDispatch is about offerring interfaces which are "interpreted" at runtime rather than "hardcoded" function calls determined at compiletime, it's what languages like VBS/VBA and JavaScript tend to use. ANd those languages will only work with the generic types.
You can call IDispatch from C++ but without some framework support for it (like ATL), it's very tedious compared to the fairly straightforward calling of interface methods.
Last edited by OReubens; April 2nd, 2014 at 06:44 AM.
Kindly tell me how to access IOleObject from the winform control. I can't use managed code in my Unmanaged library.
I'm not sure how I could help, as I know nothing about what you do and how you do what you do. I tried to assemble some sample that demonstrates how true COM object and native Object in C# differ from each other. Please find the sample attached here.
When you have the project built, run it with demo or xl command parameter to see how true COM object is passed via IUnknown to C++ code. You are going to get Succeeded in case you have demo scriptlet or MS Excel registered in your system (see README.TXT for scriptlet registration details.) Which means C++ is able to query IDispatch from the IUnknown.
And see the same for native C# Object when you specify no command line parameter. You get Failed, which means there's no any dispinterface behind the IUnknown.
See the difference.
Last edited by Igor Vartanov; April 2nd, 2014 at 10:33 AM.
COM is about interfaces (functions) and you don't know what the "inside" (data) of a COM interface really is.
Yeah, I should be more specific about interfaces. But once some interface is registered in the system (along with its coclass) you do know "what is inside" as the type library exposes the details. The thing is that type library can talk COM language only.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.