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

In diesem Thema gibt "object" das Objekt als Ganzes an, während es von einem ADSI-Client angezeigt wird. Das heißt, ADSI und alle erweiterungen.

Gleicher Funktionsname mit den gleichen 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 anhand der folgenden Kriterien bestimmt. 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 adsi vtable access aufgerufen.

Wenn eine der oben genannten Bedingungen false ist, werden IDispatch::GetIDsOfNames und IDispatch::Invoke aufgerufen, um Func1 aufrufen.

Weitere Informationen und eine kurze Erläuterung dazu, wie ein Client einen Zeiger auf eine duale Schnittstelle hinzufügen kann, sowie eine Beschreibung der Arten von Umgebungen, die vtable-Zugriff unterstützen, finden Sie unter Späte Bindung im Vergleich zum Vtable-Zugriff im ADSI-Erweiterungsmodell.

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

  • Wenn eine Schnittstelle, die im Aggregator (ADSI) nur eine beliebige Schnittstelle unterstützt, eine Funktion namens Func1 unterstützt, ruft der Aggregator seine eigene Func1 auf.
  • Andernfalls durchläuft der Aggregator jede seiner Erweiterungen in der reihenfolge, die in der Registrierung aufgeführt ist, und sucht 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 bestimmen, welche Func1 in Automation immer aufgerufen werden soll.

Gleicher Funktionsname mit unterschiedlichen Parametern

Im vorherigen Abschnitt wurde erläutert, wie Funktionsnamenkonflikte gelöst werden können, d.&a; Funktionsnamen, die denselben Funktionsnamen und dieselbe Parameterliste haben, z. B. Zahl, Typ und Reihenfolge, wenn sie in Automation auftreten. Was passiert, wenn zwei Funktionen denselben Namen, aber unterschiedliche Parameter haben? Wenn ein ADSI-Client die Funktion mithilfe von IDispatch::GetIDsOfNames aufruft, ohne mehrere Namen zum Angeben der Parameter zu verwenden, kann das ADSI-Erweiterungsmodell die Funktionen nicht mehrdeutigen. Basierend auf dem oben beschriebenen Auflösungsschema wird für die erste Erweiterung in der Registrierung, die diese Funktion über eine ihrer Schnittstellen unterstützt, die Version dieser Funktion aufgerufen, und der Aufruf kann fehlschlagen oder falsche Ergebnisse liefern.

Beispiel:

  • Extn1 (zuerst in der Registrierung unter der Klasse CA – höhere Priorität) unterstützt IInterface1.
  • Extn2 (drittes in der Registrierung unter der Klasse CA – 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 Klasse CA. 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 der gewünschten IInterface2::Method1 aufgerufen, und die Funktion schlägt fehl, da die Anzahl der Parameter unterschiedlich ist.

Um dieses Problem zu minimieren, können Erweiterungsentwickler ihren Funktionsnamen ihre eigenen spezifischen Bezeichner voran stellen und Schnittstellenentwürfe vermeiden, die Funktionen desselben 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 die IDispatch::GetIDsOfNames-Funktion mit mehreren Namen nicht aufruft. Das heißt, es wird nur der Funktionsname an GetIDsOfNames übergeben, aber keine Argumente. In Visual Basic 5 können Benutzer jedoch eine Funktion über direkten vtable-Zugriff aufrufen, anstatt die IDispatch::GetIDsOfNames-Funktion auf aufruft, wenn die Schnittstelle eine duale Schnittstelle ist. Entwickler sollten nach Möglichkeit direkten vtable-Zugriff verwenden.

Weitere Informationen zur Namenskonfliktlösung finden Sie unter Beispiel für das Auflösen von Funktionsnamenkonflikten.