Resolution of Function/Property Name Conflicts in Automation in Extensions

In this section, an object means the object, as a whole, as an ADSI client sees it. In other words, ADSI and all of its extensions.

If two or more dual IDispatch interfaces in an object support a property or method of the same name, for instance, Func1, invocation will be determined using the following criteria:

1. If the client has a pointer to one of the dual interfaces which support a method called Func1, AND,
2. If the Automation environment supports vtable access.

In the Late Binding vs. Vtable Access in the ADSI Extension Model section, there was a brief explanation about how a client can add a pointer to a dual interface, and a description of the types of environments that support vtable access. Further details can be obtained from guides for COM/OLE, Visual Basic, Visual Basic for Applications, VBScript, and JavaScript.

If both conditions are true, that is, a client has a pointer to a dual (only) interface, IDuallInf1, which supports a function called Func1, and the Automation environment supports vtable access, IDualInf1::Func1 will be invoked directly through ADSI vtable access.

If condition 1) or 2) fails, IDispatch::GetIDsOfNames and IDispatch::Invoke will be called to invoke Func1. Since all extension objects redirect the IDispatch functions back to the aggregator, the aggregator controls which Func1 will be invoked. The rules are as follows:

• If any interface, and there will only be one, if any, in the aggregator (ADSI) supports a function called Func1, the aggregator will invoke its own Func1.
• Otherwise, the aggregator will go through each of its extensions, in the order listed in the registry, and find the first extension which implements a function called Func1. It is possible, but highly unlikely, that multiple dual IDispatch interfaces in this first extension have a function called Func1. It is up to the extension to determine which Func1 should always be invoked in Automation.