Partager via

Résolution des conflits de nom de propriété/fonction dans Automation dans les extensions

  • Article

Dans cette rubrique, « object » indique l’objet, dans son ensemble, comme un client ADSI le consulte. Autrement dit, ADSI et toutes ses extensions.

Même nom de fonction avec les mêmes paramètres

Si plusieurs interfaces IDispatch doubles dans un objet prennent en charge une propriété ou une méthode du même nom, par exemple , Func1, l’appel est déterminé à l’aide des critères suivants. Si le client a un pointeur vers l’une des interfaces doubles qui prennent en charge une méthode appelée Func1 et si l’environnement Automation prend en charge l’accès aux tables virtuelles, Func1 est appelé directement via l’accès à la table virtuelle ADSI.

Si l’une des conditions ci-dessus est false, IDispatch::GetIDsOfNames et IDispatch::Invoke sont appelés pour appeler Func1.

Pour plus d’informations et une brève explication sur la façon dont un client peut ajouter un pointeur vers une interface double, ainsi qu’une description des types d’environnements qui prennent en charge l’accès aux tables virtuelles, consultez Liaison tardive ou accès À table virtuelle dans le modèle d’extension ADSI.

Étant donné que tous les objets d’extension redirigent les fonctions IDispatch vers l’agrégateur, l’agrégateur contrôle l’appel de Func1 . Les règles sont les suivantes :

  • Si une interface, et qu’il n’y en aura qu’une seule, le cas échéant, dans l’agrégateur (ADSI) prend en charge une fonction appelée Func1, l’agrégateur appelle son propre Func1.
  • Sinon, l’agrégateur passe par chacune de ses extensions, dans l’ordre indiqué dans le Registre, et recherche la première extension qui implémente une fonction appelée Func1. Il est possible, mais peu probable, que plusieurs interfaces IDispatch doubles dans cette première extension aient une fonction appelée Func1. L’extension doit déterminer quel Func1 doit toujours être appelé dans Automation.

Même nom de fonction avec des paramètres différents

La section précédente expliquait comment résoudre les conflits de noms de fonction, c’est-à-dire les noms de fonction qui ont le même nom de fonction et la même liste de paramètres, tels que le nombre, le type et l’ordre, lorsqu’ils se produisent dans Automation. Que se passe-t-il si deux fonctions ont le même nom, mais des paramètres différents ? Si un client ADSI appelle la fonction à l’aide de IDispatch::GetIDsOfNames sans utiliser plusieurs noms pour spécifier les paramètres, le modèle d’extension ADSI ne peut pas lever l’ambiguïté des fonctions. Selon le schéma de résolution décrit ci-dessus, la première extension du Registre qui prend en charge cette fonction via l’une de ses interfaces a sa version de cette fonction appelée, et l’appel peut échouer ou produire des résultats incorrects.

Par exemple :

  • Extn1 (premier dans le Registre sous l’autorité de certification de classe - priorité supérieure) prend en charge IInterface1.
  • Extn2 (troisième dans le Registre sous l’autorité de certification de classe - priorité inférieure) prend en charge IInterface2.
  • IInterface1 prend en charge Method1(int param1, int param2).
  • IInterface2 prend en charge Method1(int param1).

Un client ADSI a un pointeur d’interface IDispatch vers un objet d’autorité de certification de classe. Il souhaite appeler IInterface2::Method1. Si le client appelle « pDispatch-GetIDsOfNames>(IID_NULL, rgszNames, 1, MY_LCID, rgDispId) » en stockant simplement le nom de la fonction « Method1 » dans rgszNames[0], IInterface1::Method1 au lieu de l’IInterface2 ::Method1 souhaité est appelé, et la fonction échoue, car le nombre de paramètres est différent.

Pour réduire ce problème, les développeurs d’extensions peuvent précéder leurs noms de fonctions avec leurs propres identificateurs spécifiques et éviter les conceptions d’interface qui utilisent des fonctions du même nom, mais des paramètres différents.

Si un conflit de noms se produit, les clients ADSI peuvent éviter le problème en accédant directement aux tables virtuelles si l’interface est une interface double. Si l’accès direct aux tables virtuelles n’est pas possible, les clients ADSI doivent appeler IDispatch::GetIDsOfNames avec plusieurs noms, en spécifiant les noms de fonction ainsi que les paramètres du tableau rgszNames décrits précédemment.

Visual Basic 5 n’appelle pas la fonction IDispatch::GetIDsOfNames avec plusieurs noms. Autrement dit, il transmet uniquement le nom de la fonction à GetIDsOfNames, mais pas aux arguments. Toutefois, Visual Basic 5 permet aux utilisateurs d’appeler une fonction par accès direct à la table virtuelle, au lieu d’appeler la fonction IDispatch::GetIDsOfNames si l’interface est une double interface. Les développeurs doivent utiliser l’accès direct aux tables virtuelles, si possible.

Pour plus d’informations sur la résolution des conflits de noms, consultez Exemple de résolution des conflits de noms de fonction.