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.
Vi såg tidigare att ett objekt kan implementera mer än ett gränssnitt. Dialogrutan Common Item är ett verkligt exempel på detta. För att stödja de vanligaste användningsområdena implementerar objektet IFileOpenDialog-gränssnittet. Det här gränssnittet definierar grundläggande metoder för att visa dialogrutan och hämta information om den valda filen. För mer avancerad användning implementerar objektet dock även ett gränssnitt med namnet IFileDialogCustomize. Ett program kan använda det här gränssnittet för att anpassa utseendet och beteendet i dialogrutan genom att lägga till nya användargränssnittskontroller.
Kom ihåg att varje COM-gränssnitt måste ärva, direkt eller indirekt, från IUnknown-gränssnittet. Följande diagram visar arvet av objektet Common Item Dialog.
Som du kan se i diagrammet är den direkta föregångaren till IFileOpenDialog gränssnittet IFileDialog, vilket i sin tur ärver från IModalWindow. När du går upp i arvskedjan från IFileOpenDialog till IModalWindowdefinierar gränssnitten alltmer generaliserade fönsterfunktioner. Slutligen ärver gränssnittet IModalWindow från IUnknown. Objektet för dialogrutan Common Item implementerar också IFileDialogCustomize, som finns i en separat arvskedja.
Anta nu att du har en pekare till gränssnittet IFileOpenDialog. Hur skulle du få en pekare till IFileDialogCustomize gränssnitt?
Det går inte att kasta IFileOpenDialog pekare till en IFileDialogCustomize pekare. Det finns inget tillförlitligt sätt att "korsgjuta" över en arvshierarki, utan någon form av run-time-typinformation (RTTI), som är en mycket språkberoende funktion.
COM-metoden är att be objektet att ge dig en IFileDialogAnpassa pekare med hjälp av det första gränssnittet som en kanal till objektet. Detta görs genom att anropa metoden IUnknown::QueryInterface från den första gränssnittspekaren. Du kan se QueryInterface som en språkoberoende version av nyckelordet dynamic_cast i C++.
Metoden QueryInterface har följande signatur:
HRESULT QueryInterface(REFIID riid, void **ppvObject);
Baserat på vad du redan vet om CoCreateInstancekanske du kan gissa hur QueryInterface fungerar.
- Parametern riid är det GUID som identifierar gränssnittet som du ber om. Datatypen REFIID är en typedef- för
const GUID&. Observera att klassidentifieraren (CLSID) inte krävs eftersom objektet redan har skapats. Endast gränssnittsidentifieraren är nödvändig. - Parametern ppvObject tar emot en pekare till gränssnittet. Datatypen för den här parametern är void**, av samma anledning som CoCreateInstance använder den här datatypen: QueryInterface kan användas för att fråga efter ett COM-gränssnitt, så parametern kan inte skrivas starkt.
Så här anropar du QueryInterface för att hämta en IFileDialogCustomize pekare:
hr = pFileOpen->QueryInterface(IID_IFileDialogCustomize,
reinterpret_cast<void**>(&pCustom));
if (SUCCEEDED(hr))
{
// Use the interface. (Not shown.)
// ...
pCustom->Release();
}
else
{
// Handle the error.
}
Kontrollera som alltid HRESULT- returvärde, om metoden misslyckas. Om metoden lyckas måste du anropa Release när du är klar med pekaren, enligt beskrivningen i Hantera livslängden för ett objekt.
Nästa