Freigeben über

Lösung von Funktions-/Eigenschaftsnamenkonflikten in der Automatisierung in Erweiterungen

  • Artikel

In diesem Thema gibt "object" das Objekt als Ganzes an, als ein ADSI-Client es anzeigt. Das heißt, ADSI und alle zugehörigen Erweiterungen.

Gleicher Funktionsname mit denselben Parametern

Wenn zwei oder mehr duale IDispatch-Schnittstellen in einem Objekt eine Eigenschaft oder Methode mit demselben Namen unterstützen, z. B . Func1, wird der Aufruf mithilfe der folgenden Kriterien ermittelt. Wenn der Client über einen Zeiger auf eine der dualen Schnittstellen verfügt, die eine Methode namens Func1 unterstützen und die Automation-Umgebung vtable-Zugriff unterstützt, wird Func1 direkt über den ADSI-vtable-Zugriff aufgerufen.

Wenn eine der obigen Bedingungen false ist, werden IDispatch::GetIDsOfNames und IDispatch::Invoke aufgerufen, um Func1 aufzurufen.

Weitere Informationen und eine kurze Erklärung darüber, wie ein Client einen Zeiger auf eine duale Schnittstelle hinzufügen kann, sowie eine Beschreibung der Typen von Umgebungen, die den vtable-Zugriff unterstützen, finden Sie unter Spätbindung und Vtable-Zugriff im ADSI-Erweiterungsmodell.

Da alle Erweiterungsobjekte die IDispatch-Funktionen zurück an den Aggregator weiterleiten, steuert der Aggregator, welcher Func1 aufgerufen wird. Die Regeln lauten:

  • Wenn eine Schnittstelle und nur eine , falls vorhanden, im Aggregator (ADSI) eine Funktion namens Func1 unterstützt, ruft der Aggregator seinen eigenen Func1 auf.
  • Andernfalls durchläuft der Aggregator jede seiner Erweiterungen in der in der Registrierung aufgeführten Reihenfolge und findet die erste Erweiterung, die eine Funktion namens Func1 implementiert. Es ist möglich, aber unwahrscheinlich, dass mehrere duale IDispatch-Schnittstellen in dieser ersten Erweiterung über eine Funktion namens Func1 verfügen. Die Erweiterung muss festlegen, welcher Func1 in Automation immer aufgerufen werden soll.

Gleicher Funktionsname mit unterschiedlichen Parametern

Im vorherigen Abschnitt wurde erläutert, wie Sie Funktionsnamenkonflikte auflösen, d. h. Funktionsnamen, die denselben Funktionsnamen und dieselbe Parameterliste aufweisen, z. B. Zahl, Typ und Reihenfolge, wenn dies in Automation auftritt. Was geschieht, wenn zwei Funktionen denselben Namen, aber unterschiedliche Parameter haben? Wenn ein ADSI-Client die Funktion mit IDispatch::GetIDsOfNames aufruft , ohne mehrere Namen zum Angeben der Parameter zu verwenden, kann das ADSI-Erweiterungsmodell die Funktionen nicht eindeutig definieren. Basierend auf dem oben beschriebenen Lösungsschema wird die erste Erweiterung in der Registrierung, die diese Funktion über eine ihrer Schnittstellen unterstützt, ihre Version dieser Funktion aufgerufen, und der Aufruf kann fehlschlagen oder falsche Ergebnisse liefern.

Beispiel:

  • Extn1 (zuerst in der Registrierung unter Klassenzertifizierungsstelle – höhere Priorität) unterstützt IInterface1.
  • Extn2 (dritter In der Registrierung unter der Klassenzertifizierungsstelle – niedrigere Priorität) unterstützt IInterface2.
  • IInterface1 unterstützt Method1(int param1, int param2).
  • IInterface2 unterstützt Method1(int param1).

Ein ADSI-Client verfügt über einen IDispatch-Schnittstellenzeiger auf ein Objekt der Klassenzertifizierungsstelle. Sie möchte IInterface2::Method1 aufrufen. Wenn der Client "pDispatch-GetIDsOfNames>(IID_NULL, rgszNames, 1, MY_LCID, rgDispId)" aufruft, indem er einfach den Funktionsnamen "Method1" in rgszNames[0] speichert, wird IInterface1::Method1 anstelle des gewünschten IInterface2::Method1 aufgerufen, und die Funktion schlägt fehl, da sich die Anzahl der Parameter unterscheidet.

Um dieses Problem zu minimieren, können Erweiterungsentwickler ihren Funktionsnamen ihre eigenen spezifischen Bezeichner voran stellen und Schnittstellendesigns vermeiden, die Funktionen des gleichen Namens, aber unterschiedliche Parameter verwenden.

Wenn ein Namenskonflikt auftritt, können ADSI-Clients das Problem durch direkten Vtable-Zugriff vermeiden, wenn es sich bei der Schnittstelle um eine duale Schnittstelle handelt. Wenn kein direkter vtable-Zugriff möglich ist, sollten ADSI-Clients IDispatch::GetIDsOfNames mit mehreren Namen aufrufen und dabei die Funktionsnamen sowie die Parameter im zuvor beschriebenen Array rgszNames angeben.

Visual Basic 5 ruft die IDispatch::GetIDsOfNames-Funktion nicht mit mehreren Namen auf. Das heißt, es übergibt nur den Funktionsnamen an GetIDsOfNames, aber nicht an Argumente. Visual Basic 5 ermöglicht benutzern jedoch das Aufrufen einer Funktion durch direkten Vtable-Zugriff, anstatt die IDispatch::GetIDsOfNames-Funktion aufzurufen, wenn es sich bei der Schnittstelle um eine duale Schnittstelle handelt. Entwickler sollten nach Möglichkeit direkten vtable-Zugriff verwenden.

Weitere Informationen zur Konfliktlösung finden Sie unter Beispiel zum Auflösen von Funktionsnamenkonflikten.