More on the Resolution of Automation Conflicts: Same Function Name but Different Parameters

In Resolution of Function/Property Name Conflicts in Automation in Extensions, there was discussion about how to resolve function name conflicts, that is, function names that use the same function name and same parameter list (number, type and order), when it occurs in Automation. But what if two functions have the same name but different parameters? Unfortunately, if an ADSI client invokes the function using IDispatch::GetIDsOfNames without using multiple names to specify the parameters, the ADSI extension model cannot disambiguate the functions. Based on the resolution scheme discussed in Resolution of Function/Property Name Conflicts in Automation in Extensions, the first extension in the registry which supports this function through one of its interfaces will have its version of this function invoked, and the call may fail or yield incorrect results.

For example:

Extn1 (first in the registry under class CA – higher priority) supports IInterface1.

Extn2 (third in the registry under class CA – lower priority) supports IInterface2.

IInterface1 supports Foo1(int param1, int param2).

IInterface2 supports Foo1(int param1)

An ADSI client has an IDispatch interface pointer to an object of class CA. It wants to invoke IInterface2::Foo1. If the client calls pDispatch->GetIDsOfNames(IID_NULL, rgszNames, 1, MY_LCID, rgDispId) by just storing the function name "Foo1" in rgszNames[0], then IInterface1::Foo1, instead of the desired IInterface2::Foo1 will be invoked, and the function will fail since the number of parameters are different.

To minimize this problem, extension developers can prefix their function names with their own specific identifiers and avoid interface designs that use functions of the same name but different parameters.

If a name conflict does occur, ADSI clients can avoid the problem by direct vtable access if the interface is a dual interface (see the discussion in the previous section). If direct vtable access is not possible, ADSI clients should call IDispatch::GetIDsOfNames with multiple names, specifying the function names as well as the parameters in the array rgszNames described previously.

Visual Basic 5 does not call the IDispatch::GetIDsOfNames function with multiple names. That is, it only passes the function name to GetIDsOfNames, but not arguments. However, Visual Basic 5 allows users to invoke a function by direct vtable access (see the previous discussion), instead of invoking the IDispatch::GetIDsOfNames function if the interface is a dual interface. Developers should use direct vtable access, if possible.