Directory Services

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

Resolution of Function/Property Name Conflicts in Automation in Extensions discussed how to resolve function name conflicts, that is, function names that use the same function name and same parameter list, such as number, type and order, when it occurs in Automation. But what if two functions have the same name but different parameters? 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 that supports this function through one of its interfaces has its version of this function invoked, and the call may fail or yield incorrect results.

For example:

An ADSI client has an IDispatch interface pointer to an object of class CA. It wants to invoke IInterface2::Method1. If the client calls pDispatch->GetIDsOfNames(IID_NULL, rgszNames, 1, MY_LCID, rgDispId) by just storing the function name "Method1" in rgszNames[0], then IInterface1::Method1, instead of the desired IInterface2::Method1 is invoked, and the function fails because 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. 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 passes only the function name to GetIDsOfNames, but not arguments. However, Visual Basic 5 allows users to invoke a function by direct vtable access, instead of invoking the IDispatch::GetIDsOfNames function if the interface is a dual interface. Developers should use direct vtable access, if possible.