Resolución de conflictos de nombre de función/propiedad en automatización en extensiones

En este tema, "object" indica el objeto, en su conjunto, como un cliente ADSI lo ve. Es decir, ADSI y todas sus extensiones.

Mismo nombre de función con los mismos parámetros

Si dos o más interfaces IDispatch duales en un objeto admiten una propiedad o método del mismo nombre, por ejemplo, Func1, la invocación se determina mediante los siguientes criterios. Si el cliente tiene un puntero a una de las interfaces duales que admiten un método denominado Func1 y si el entorno de Automation admite el acceso a vtable, se invoca func1 directamente a través del acceso vtable adsI.

Si alguna de las condiciones anteriores es false, se llama a IDispatch::GetIDsOfNames y IDispatch::Invoke para invocar Func1.

Para obtener más información y una breve explicación sobre cómo un cliente puede agregar un puntero a una interfaz dual y una descripción de los tipos de entornos que admiten el acceso a vtable, vea Enlace en tiempo de ejecución frente a acceso Vtable en el modelo de extensión ADSI.

Dado que todos los objetos de extensión redirigen las funcionesIDispatch al agregador, se invocan los controles de agregador que func1. Las reglas son:

• Si alguna interfaz y solo habrá una, si existe, en el agregador (ADSI) admite una función denominada Func1, el agregador invoca su propio Func1.
• De lo contrario, el agregador pasa por cada una de sus extensiones, en el orden enumerado en el Registro, y busca la primera extensión que implementa una función denominada Func1. Es posible, pero poco probable, que varias interfaces de IDispatch duales en esta primera extensión tengan una función denominada Func1. La extensión debe determinar qué func1 debe invocarse siempre en Automation.

Mismo nombre de función con parámetros diferentes

En la sección anterior se explicó cómo resolver conflictos de nombres de función, es decir, nombres de función que tienen el mismo nombre de función y la misma lista de parámetros, como el número, el tipo y el orden, cuando se produce en Automation. ¿Qué ocurre si dos funciones tienen el mismo nombre pero parámetros diferentes? Si un cliente ADSI invoca la función mediante IDispatch::GetIDsOfNames sin usar varios nombres para especificar los parámetros, el modelo de extensión ADSI no puede desambiguar las funciones. En función del esquema de resolución descrito anteriormente, la primera extensión del Registro que admite esta función a través de una de sus interfaces tiene su versión de esta función invocada y la llamada puede producir un error o producir resultados incorrectos.

Por ejemplo:

• Extn1 (primero en el registro bajo la ca de clase , prioridad más alta) admite IInterface1.
• Extn2 (tercero en el registro bajo la ca de clase , prioridad inferior) admite IInterface2.
• IInterface1 admite Method1(int param1, int param2).
• IInterface2 admite Method1(int param1).

Un cliente ADSI tiene un puntero de interfazIDispatch a un objeto de ca de clase. Quiere invocar IInterface2::Method1. Si el cliente llama a "pDispatch->GetIDsOfNames(IID_NULL, rgszNames, 1, MY_LCID, rgDispId)" simplemente almacenando el nombre de función "Method1" en rgszNames[0], luego IInterface1::Method1 en lugar de la IInterface2::Method1 se invoca y se produce un error en la función porque el número de parámetros es diferente.

Para minimizar este problema, los desarrolladores de extensiones pueden prefijar sus nombres de función con sus propios identificadores específicos y evitar diseños de interfaz que usen funciones del mismo nombre, pero parámetros diferentes.

Si se produce un conflicto de nombres, los clientes ADSI pueden evitar el problema mediante el acceso directo a vtable si la interfaz es una interfaz dual. Si el acceso directo a vtable no es posible, los clientes ADSI deben llamar a IDispatch::GetIDsOfNames con varios nombres, especificando los nombres de función, así como los parámetros de la matriz rgszNames descritos anteriormente.

Visual Basic 5 no llama a la función IDispatch::GetIDsOfNames con varios nombres. Es decir, pasa solo el nombre de la función a GetIDsOfNames, pero no argumentos. Sin embargo, Visual Basic 5 permite a los usuarios invocar una función mediante acceso directo a vtable, en lugar de invocar la IDispatch::GetIDsOfNames función si la interfaz es una interfaz dual. Los desarrolladores deben usar el acceso directo a vtable, si es posible.

Para obtener más información sobre la resolución de conflictos de nombres, vea ejemplo para resolver conflictos de nombre de función.