Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I det här avsnittet anger "objekt" objektet som helhet när en ADSI-klient visar det. Det vill: ADSI och alla dess tillägg.
Samma funktionsnamn med samma parametrar
Om två eller flera dubbla IDispatch--gränssnitt i ett objekt stöder en egenskap eller metod med samma namn, till exempel Func1, bestäms anropet med hjälp av följande villkor. Om klienten har en pekare till ett av de dubbla gränssnitten som stöder en metod som kallas Func1 och om Automation-miljön stöder vtable-åtkomst anropas Func1 direkt via ADSI-vtable-åtkomst.
Om något av villkoren ovan är falskt anropas IDispatch::GetIDsOfNames och IDispatch::Anropa för att anropa Func1.
Mer information och en kort förklaring om hur en klient kan lägga till en pekare i ett dubbelt gränssnitt och en beskrivning av de typer av miljöer som stöder vtable-åtkomst finns i Late Binding kontra Vtable Access i ADSI Extension Model.
Eftersom alla tilläggsobjekt omdirigerar IDispatch funktioner tillbaka till aggregatorn, styr aggregatorn som Func1 anropas. Reglerna är:
- Om något gränssnitt, och det bara finns ett, om något, i aggregatorn (ADSI) stöder en funktion som heter Func1anropar aggregatorn sin egen Func1.
- Annars går aggregatorn igenom vart och ett av sina tillägg i den ordning som anges i registret och hittar det första tillägget som implementerar en funktion som heter Func1. Det är möjligt, men osannolikt, att flera dubbla IDispatch--gränssnitt i det här första tillägget har en funktion som heter Func1. Tillägget måste avgöra vilka Func1- alltid ska anropas i Automation.
Samma funktionsnamn med olika parametrar
I föregående avsnitt diskuterades hur du löser konflikter med funktionsnamn, det vill ex. funktionsnamn som har samma funktionsnamn och samma parameterlista, till exempel nummer, typ och ordning, när det inträffar i Automation. Vad händer om två funktioner har samma namn men olika parametrar? Om en ADSI-klient anropar funktionen med hjälp av IDispatch::GetIDsOfNames utan att använda flera namn för att ange parametrarna, kan ADSI-tilläggsmodellen inte skilja funktionerna åt. Baserat på det lösningsschema som beskrivs ovan har det första tillägget i registret som stöder den här funktionen via ett av dess gränssnitt sin version av den här funktionen anropad, och anropet kan misslyckas eller ge felaktiga resultat.
Till exempel:
- Extn1 (först i registret under klassen CA – högre prioritet) stöder IInterface1.
- Extn2 (tredje i registret under klass-CA – lägre prioritet) stöder IInterface2.
- IInterface1 stöder Method1(int param1, int param2).
- IInterface2 stöder Method1(int param1).
En ADSI-klient har en IDispatch- gränssnittspekare till ett objekt i klassen CA. Den vill anropa IInterface2::Method1. Om klienten anropar "pDispatch–>GetIDsOfNames(IID_NULL, rgszNames, 1, MY_LCID, rgDispId)" genom att bara lagra funktionsnamnet "Method1" i rgszNames[0]och sedan IInterface1::Method1 i stället för önskad IInterface2::Method1 anropas och funktionen misslyckas eftersom antalet parametrar skiljer sig.
För att minimera det här problemet kan tilläggsutvecklare prefixa sina funktionsnamn med sina egna specifika identifierare och undvika gränssnittsdesigner som använder funktioner med samma namn, men olika parametrar.
Om det uppstår en namnkonflikt kan ADSI-klienter undvika problemet genom direkt vtable-åtkomst om gränssnittet är ett dubbelt gränssnitt. Om direkt vtable-åtkomst inte är möjlig bör ADSI-klienter anropa IDispatch::GetIDsOfNames med flera namn, ange funktionsnamnen samt parametrarna i matrisen rgszNames som beskrevs tidigare.
Visual Basic 5 anropar inte funktionen IDispatch::GetIDsOfNames med flera namn. Det vill:et skickar bara funktionsnamnet till GetIDsOfNames, men inte argument. Visual Basic 5 tillåter dock användare att anropa en funktion via direkt vtable-åtkomst, i stället för att anropa IDispatch::GetIDsOfNames funktion om gränssnittet är ett dubbelt gränssnitt. Utvecklare bör använda direkt vtable-åtkomst, om möjligt.
Mer information om lösning av namnkonflikter finns i Exempel för att lösa funktionsnamnskonflikter.