Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema gibt "object" das Objekt als Ganzes an, da ein ADSI-Client es anzeigt. Das heißt, ADSI und alle seine Erweiterungen.
Identischer 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 bestimmt. Wenn der Client über einen Zeiger auf eine der dualen Schnittstellen verfügt, die eine Methode namens Func1 unterstützen und wenn die Automatisierungsumgebung vtable-Zugriff unterstützt, wird Func1 direkt über ADSI vtable-Zugriff aufgerufen.
Wenn eine der oben genannten Bedingungen falsch ist, werden IDispatch::GetIDsOfNames und IDispatch::Invoke aufgerufen, um Func1aufzurufen.
Weitere Informationen und eine kurze Erläuterung dazu, wie ein Client einen Zeiger zu einer dualen Schnittstelle hinzufügen kann, und eine Beschreibung der Typen von Umgebungen, die den vtable-Zugriff unterstützen, finden Sie unter Late Binding versus Vtable Access im ADSI Extension Model.
Da alle Erweiterungsobjekte die IDispatch- Funktionen zurück an den Aggregator umleiten, steuert der Aggregator, der Func1 aufgerufen wird. Die Regeln sind:
- Wenn eine Schnittstelle vorhanden ist und im Aggregator (ADSI) nur eine Funktion namens Func1unterstützt, ruft der Aggregator seine eigene Func1auf.
- 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 Func1implementiert. Es ist möglich, aber unwahrscheinlich, dass mehrere duale IDispatch--Schnittstellen in dieser ersten Erweiterung eine Funktion namens Func1haben. Die Erweiterung muss bestimmen, welche Func1- immer in der Automatisierung aufgerufen werden soll.
Identischer Funktionsname mit unterschiedlichen Parametern
Im vorherigen Abschnitt wurde erläutert, wie Funktionsnamenkonflikte behoben werden, d. h. Funktionsnamen mit demselben Funktionsnamen und derselben Parameterliste, z. B. Zahl, Typ und Reihenfolge, wenn sie in der Automatisierung auftritt. Was geschieht, wenn zwei Funktionen denselben Namen haben, aber unterschiedliche Parameter? 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 mehrdeutig machen. Basierend auf dem oben beschriebenen Lösungsschema hat die erste Erweiterung in der Registrierung, die diese Funktion über eine seiner Schnittstellen unterstützt, seine Version dieser Funktion aufgerufen, und der Aufruf schlägt fehl oder liefert falsche Ergebnisse.
Zum Beispiel:
- Extn1 (first in the registry under class CA – higher priority) supports IInterface1.
- Extn2 (Dritter in der Registrierung unter 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. Es möchte IInterface2::Method1aufrufen. Wenn der Client "pDispatch->GetIDsOfNames(IID_NULL) aufruft, rgszNames, 1, MY_LCID, rgDispId)" durch Speichern des Funktionsnamens "Method1" in rgszNames[0], dann IInterface1::Method1 anstelle der gewünschten IInterface2::Method1 aufgerufen wird, und die Funktion schlägt fehl, da die Anzahl der Parameter unterschiedlich ist.
Um dieses Problem zu minimieren, können Erweiterungsentwickler ihren Funktionsnamen eigene spezifische Bezeichner voranstellen und Schnittstellendesigns vermeiden, die Funktionen desselben Namens verwenden, aber unterschiedliche Parameter.
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 der direkte vtable-Zugriff nicht möglich ist, sollten ADSI-Clients IDispatch::GetIDsOfNames mit mehreren Namen aufrufen und die Funktionsnamen sowie die Parameter im Array rgszNames beschrieben angeben.
Visual Basic 5 ruft die IDispatch::GetIDsOfNames- Funktion mit mehreren Namen nicht auf. Das heißt, er ü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 die Schnittstelle eine duale Schnittstelle ist. Entwickler sollten nach Möglichkeit direkten vtable-Zugriff verwenden.
Weitere Informationen zur Namenskonfliktauflösung finden Sie unter Beispiel zum Auflösen von Funktionsnamenkonflikten.