Compartir a través de

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

  • Artículo

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 un método con el mismo nombre, por ejemplo, Func1, la invocación se determina mediante los criterios siguientes. 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 la tabla virtual, Func1 se invoca directamente a través del acceso a ADSI vtable.

Si alguna de las condiciones anteriores es false, se llama a IDispatch::GetIDsOfNames e 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 vtable, consulte 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 funciones IDispatch de nuevo al agregador, el agregador controla qué Func1 se invoca. 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 encuentra la primera extensión que implementa una función denominada Func1. Es posible, pero poco probable, que varias interfaces IDispatch duales de esta primera extensión tengan una función llamada 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 número, tipo y 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 interfaz IDispatch 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 la función "Method1" en rgszNames[0], IInterface1::Method1 en lugar del IInterface2::Method1 deseado 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 la tabla virtual 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 el acceso directo a vtable, en lugar de invocar la función IDispatch::GetIDsOfNames 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.