Re: dual interface - C / C++ / MFC Discussion Boards

Scott Holt22-Sep-08 2:25

22-Sep-08 2:25

Yes, the VARIANT data type IS "automation-compatible". In fact, the last time I checked, all parameters to the IDispatch interface HAD to be VARIANT. Thus, your phrase "means if a data type could be represented by VARIANT, it is automation compatible" is TRUE.

I am not sure where you found something that indicates that a VARIANT is not an ole automation data type, but I think what you found is in error.

There are other data types that can be marshalled between a COM client and a COM server, but you must use VARIANT with the IDispatch interface.

Now, in the early days, "automation" was referred to as "OLE automation", where the acronym "OLE" meant "Object Linking and Embedding". This was a phrase that Microsoft used to describe its early techonologies for allowing their Office applications to work with each other. "OLE automation" was the precursor to COM. Later on, the VB team at Microsoft created the IDispatch interface, "OLE automation" bcame the foundation for "ActiveX" controls, people dropped the acronym "OLE" and simply started referring to "OLE automation" as just "automation", and the VB folks defined "automation" as meaning "a COM component that supports the IDispatch interface".

These days, however, "automation" is generally accepted to mean simply "a software component that adheres to the COM specification", even if it does not support IDispatch. (Remember, a COM component does not have to support IDispatch.)

Now, if you have ever programmed in VB, you know that you can use a variable without first declaring it. When you do this, VB automatically creates a variable of type...VARIANT. From the outset, VB is designed to be very flexible with regard to its data types, and because VB was both a compiled language AND a scripted language, the VARIANT data type was very convenient for passing data between software components that were bound at run-time (as with VB script).

So, you can see why VARIANT is so important to the IDispatch interface. The VB folks at Microsoft had a strong influence on COM and the IDispatch interface. They were also very interested in the use of ActiveX controls (COM components) in VB form applications, and web-based applications using VB script.

So, the moral of the story is: VARIANT is an "automation-compatible" data type, and is in fact probably the most commonly used data type for passing data between COM components.

Now, there are other "automation" data types, for example BSTR. You can pass a BSTR between a COM client and a COM server. The "marshalling" code produced by the MIDL compliler handles BSTR values quite nicely. So, VARIANT is not the only "automation" data type, but you could easily use VARIANT for ALL of your parameters if you wanted to.

This is what I do: All parameters passed between my COM clients and my COM servers are either VARIANTs, BSTRs, or long integers (four-byte integer values). Once I get the data inside my COM client or my COM server, I will typecast or convert the data into whatever type or structure I need to maniuplate the data "inside" the client or server code. If/when I need to send the data back to the client/server, I simply convert back to VARIANT, BSTR, or long integer.

Scott
Smile | :)