My question is: what is the correct usage of the version tag in an IDL file that defines COM interfaces and classes and enums?
The MSN documentation of it is confusing: the first paragraph under "Remarks" seems to clearly say that the IID must be changed if anything changes in the interface.
But the rest of the page goes on to describe using differing versions with the same IID. There is even one of the sample COM interface pages that shows using version with interface.
What's going on?
Additional question: is it permitted to use version with an enum ? MIDL 7.00.05555 accepts the version attribute for enum, however if a versioned enum is used as a function parameter, MIDL gives an error.
[version] attribute applies to DCE-RPC interfaces, not to COM interfaces (MIDL compiler supports both). Witness two quotes from the first article you cite:
The [version] interface attribute identifies a particular version among multiple versions of an RPC interface. (emphasis mine)
The MIDL compiler does not support multiple versions of a COM interface. As a result, an interface attribute list that includes the [object] attribute cannot include the [version] attribute.
In COM programming, the only useful place you could apply a [version] attribute is on a library clause. Type libraries support versioning.
Related
I want to use the COM object with the progID Windows.Contact.1 via ActiveScripting (JScript, VBScript, Python, etc).
This COM resides in C:\Program Files (x86)\Common Files\System\wab32.dll. It seems, there is no TypeLib available for it. The COM delivers, amongst others, IContact for the "Windows Address Book" (storing contacts as XML in folders, as in Windows 7). IContact is documented here.
In JScript I did:
var co = new ActiveXObject("Windows.Contact.1");
typeof co; // results in: unknown
Since it results in unknown, I have the suspicion, that this COM could not be usable for scripting. Somewhere I read, that everything, that inherits from IUnknown can not be used for scripting, instead it must inherit from IDispatch. But I am unsure, as to how much of this is valid, and whether there are workarounds.
I would like to ask for acknowledgement of my suspicions (since I am new to all of this and have no C++ or C# background) or to ask for a way, as to how to use Windows.Contact.1 from scripting, including a way, to find out, which methods/objects I can use, without resorting to a TypeLib.
I have access to pages like Programming Windows Contacts and related ones, but first I need to get an instance in ActiveScript (JScript, VBScript, Python, Lua will do). I also have access to applications like "MS OLE View" and "OLEView DotNet". Thank you.
There are entire books on the subject, but here's a very simplified story. There are basically 3 "categories" of COM interfaces:
Interfaces deriving from IUnknown
aliases for programming against: early binding, (custom) vtable binding
the simplest way to implement a COM "server"
it's only a binary contract (methods layout, method signature, parameters behavior like in/out for cross-apartment/process support, ...)
you need to somewhow tell your callers what is this binary contract you support (you can use .idl, .tlb or anything that your caller can understand)
there are some official ways of documenting your IUnknown-derived interfaces: .idl -> .h and .tlb is the most standard one
only supported by a certain class of languages (for example C/C++, .NET, Delphi), those who understand .tlb (or .idl, or equivalent .h), or those who allow redefining layout manually (like .NET). You can perfectly define a language that can do that w/o ever using .tlb. That's the beauty of COM, it's just a binary contract.
if your language doesn't support it, you just can't use it, you'll have to write or use a wrapper with a language that supports it and exposes it in a way your language supports. Powershell for example doesn't support IUnknown-derived interfaces (I'm not 100% sure) but supports .NET so it can use .NET as a "super wrapper".
IDispatch interface
only requires one IUnknown well-known interface implementation: IDispatch
aliases for programming against: late binding, OLE automation, COM automation, or simply Automation (not to confuse with UI Automation)
invented for higher level languages (VB/VBA first, ActiveScripting a bit later)
only supported by a certain class of language, and the way it's supported varies (for example it's supported in C++ of course but it's not super easy w/o wrappers or tooling like Visual Studio's C++ #import directive). JScript and VBScript don't exactly support the same set of features with regards to Automation.
you're supposed to use only a predefined list of types "Automation-Compatible types":
these types where initially very related to VB/VBA (VARIANT, SAFEARRAY, BSTR which means "Basic String"...)
from the higher level language, it really makes COM much transparent and easier as that was the whole point (and can make it harder from the lower level ones...), it also allows "syntactic sugar" niceties
note the IDispatch implementation can be very dynamic and really late-bound at runtime (get id of name -> invoke) but most available programming tooling quite freezes the list of ids/names at compile time (ex: .NET) because they support Dual interfaces.
Dual interfaces:
interfaces that implement a custom IDispatch-derived interface and implement IDispatch itself to match the custom interface (both implementations supposedly being "equivalent" of course). Have a look at the link below, it has nice images.
because of IDispatch, you're supposed to use only Automation compatible data types in the IDispatch-derived method.
it's more work to implement (so it's usually done by programming tools, for ex: ATL)
a bit easier for native (C/C++, etc.) callers (no need to use IDispatch wrappers) but you still have to digest automation data types
IMHO, one of the best 1-page introduction to COM is here: Introduction to COM
I have a COM component that has get_XXX and put_XXX methods inside it. I used it in a .NET project and a RCW was generated for it. I now see get_XXX and set_XXX methods and NOT the put_XXX one? Is that automatic or defined somewhere in IDL?
These are property accessor methods. A compiler that uses the COM server is expected to generate a call to get_Xxx() when the client program reads the property, put_Xxx() when it writes it. A special one that C# doesn't have at all is putref_Xxx(), used to unambiguously access an object instead of a value.
The normal translation performed by Tlbimp.exe is as a plain C# property. But that doesn't always work, C# is a lot more strict about what a property can look like:
The default property, the one that's annotated as DISPID_VALUE (dispid 0) must take a single argument to be compatible. This maps to the C# indexer property, the one that makes it look like you are indexing an array.
Any other property cannot take an argument, C# does not supported indexed properties other than the indexer.
C# does not have the equivalent of putref_Xxx(), the syntax ambiguity cannot occur in a C# program because of the previous two bullets. And the core reason that the C# team decided to put these restrictions in place, they greatly disliked ambiguity in the language.
So Tlbimp.exe is forced to deal with these restrictions, if the COM property accessors are not compatible then it must fall back to exposing them as plain methods instead of a property. With default names, they'll get the get_ and set_ prefixes. The latter one explains your question, they didn't pick put_ for an otherwise unclear reason.
Notable is that C# version 4 relaxed several of these restrictions, most of all to make interop with Office programs easier. Which was quite painful in earlier C# versions, to put it mildly. It extended the property syntax to lessen the pain, but only for COM interop. Very strongly recommended if you are still stuck on an old version of .NET, now is a good time to consider updating.
The properties themselves have to prefixes (put_ etc.), they have names, getter method, setter method, but no prefixes. Method table generated from type library receives prefixes to distinguish between getters and setters, hence the prefixes. Prefix string exactly depends on preference of the one who generates the names.
See also:
#pragma import attributes - raw_property_prefixes
By default, low-level propget, propput, and propputref methods are exposed by member functions named with prefixes of get_, put_, and putref_ respectively. These prefixes are compatible with the names used in the header files generated by MIDL.
I have a COM interface GUID but I don't know that interface definition. I don't know what methods it has, what parameters they have and so on. How can I obtain such information? Is it possible in general?
Practical problem is obtaining interface definition for few COM interfaces defined in actxprxy.dll. For example IFileDialogPrivate ({AC92FFC5-F0E9-455A-906B-4A83E74A803B}). (Obviously the interface is not documented and the name does suggest there is a reason for that.) I tried to use OLE/COM Object Viewer (OleView.exe) for that but wasn't able to get the interface definition.
I am trying to implement IFileDialogPrivate while doing some experiments on forcing IExplorerBrowser control to filter Windows 7 library folders. IFileDialog (which seems to use IExplorerBrowser) does it somehow and IExplorerBrowser askes service provider for IFileDialog and IFileDialogPrivate if ICommDlgBrowser is provided so I tryied to explore that interface. (Also it asks for few other interestingly named interface - could be useful).
I am creating a COM library with Embarcadero C++ Builder. The designer for the ridl file gives several things you can add to the ridl. I think I understand all of them except for creating new "Modules". I can't find good information for it in the documentation.
What is a "Module" and what would it be used for in COM?
You say you can't find 'good information' in the documentation; what have you found? The RAD Studio help has a section specifically explaining modules, which says:
A module defines a group of functions,
typically a set of DLL entry points.
You define a module by
Specifying a DLL that it represents on the attributes page.
Adding methods and constants using the toolbar or the object list pane
context menu. For each method or
constant, you must then define its
attributes by selecting the it in the
object list pane and setting the
values on the Attributes page.
For module methods, you must assign a
name and DLL entry point using the
attributes page. Declare the
function's parameters and return type
using the parameters page.
For module constants, use the
Attributes page to specify a name,
type, and value.
Note: The Type Library Editor does not generate any declarations or
implementation related to a module.
The specified DLL must be created as a
separate project.
It seems it's specifying methods that exist in an external DLL to whatever module (EXE or DLL) the type library is built into. Exactly what that's used for... is a good question.
The module attribute is described in this MSDN Library page. It permits declaring entrypoints in a DLL. That has little to do with COM, it is just a capability of a type library. You'll find few language development environments that can use them. I think VB6 was one of them. Ymmv.
I have found many references to this term on the web, especially on Microsoft's MSDN website, and even lists of such languages. However, I can't find a definition of this term. (Is it something as simple as a language for which a COM interface has been implemented?)
Please let me know if you know of a link to a definition.
Thanks.
Stripped down to bare essentials, to understand COM you have to understand GUIDs and IUnknown. The equivalent for Automation is ProgIDs and IDispatch.
A ProgID helps you create a COM coclass. A typical ProgID is "Word.Automation", the progid for Microsoft Word. You'll find them listed in the Registry under HKEY_CLASSES_ROOT. A typical name for a helper function in your language is CreateObject(). You pass it the ProgID, optionally a machine name, and you get back an interface reference. Which you can then use to make method calls and get/set properties.
The language runtime uses the IDispatch interface (retrieved with IUnknown::QueryInterface) to discover the names and parameters of the methods that are implemented by the COM server. This is called late-binding, the way any scripting language uses Automation. It has only 4 methods:
IDispatch::GetTypeInfoCount(), returns 1 if the server can provide type info
IDispatch::GetTypeInfo(), returns type information, helpful to make type-safe calls
IDispatch::GetIDsOfNames(), maps an identifier name to a number
IDispatch::Invoke(), calls a numbered method or property getter/setter.
That's all it takes.
In Microsoft Windows applications
programming, OLE Automation (later
renamed by Microsoft to just
Automation,1[2] although the old
term remained in widespread use), is
an inter-process communication
mechanism based on Component Object
Model (COM) that was intended for use
by scripting languages – originally
Visual Basic – but now are used by
languages run on Windows.[3] It
provides an infrastructure whereby
applications called automation
controllers can access and manipulate
(i.e. set properties of or call
methods on) shared automation objects
that are exported by other
applications.
From Wikipedia entry