Freigeben über

Implementieren eines Protokollhandlers für WDS

  • Artikel

Hinweis

Windows Desktop Search 2.x ist eine veraltete Technologie, die ursprünglich als Add-In für Windows XP und Windows Server 2003 verfügbar war. Verwenden Sie in späteren Versionen stattdessen Windows Search .

Das Erstellen eines Protokollhandlers umfasst die Implementierung von ISearchProtocol zum Verwalten von UrlAccessor-Objekten, IUrlAccessor zum Generieren von Metadaten und zum Identifizieren geeigneter Filter für Elemente im Datenspeicher, IProtocolHandlerSite zum Instanziieren eines SearchProtocol-Objekts und identifizieren geeigneter Filter, und IFilterzum Filtern proprietärer Dateien oder zum Auflisten und Filtern hierarchisch gespeicherter Dateien. Der Protokollhandler muss multithreadiert sein.

Dieser Abschnitt enthält die folgenden Themen:

Hinweis zu URLs

Microsoft Windows Desktop Search (WDS) verwendet URLs, um Elemente in einem Dateisystem, in einem datenbankähnlichen Speicher oder im Web eindeutig zu identifizieren. Eine URL, die einen Eintragsknoten definiert, wird als Startseite bezeichnet. WDS beginnt auf dieser Startseite und durchforstet den Datenspeicher rekursiv. Die typische URL-Struktur ist:

protocol://host/path/name.extension

Hinweis

Wenn Sie einen neuen Datenspeicher hinzufügen möchten, müssen Sie einen Namen auswählen, um ihn zu identifizieren, der nicht in Konflikt mit aktuellen Datenspeichern steht. Wir empfehlen diese Namenskonvention: companyName.scheme.

 

Protokollhandlerschnittstellen

ISearchProtocol

Die ISearchProtocol-Schnittstelle ruft UrlAccessor-Objekte auf, initialisiert und verwaltet sie. Weitere Informationen zum Implementieren der ISearchProtocol-Schnittstelle finden Sie unter Referenz zur ISearchProtocol-Schnittstelle.

IUrlAccessor

Für eine angegebene URL generiert die IUrlAccessor-Schnittstelle Metadaten zur Standortstruktur sowie enthaltene Elemente und bindet diese Elemente an einen Filter. Das IUrlAccessor-Objekt wird durch ein SearchProtocol-Objekt instanziiert und initialisiert. Sie können jedoch auch eine interne Initialisierungsmethode implementieren, damit Ihr IUrlAccessor-Objekt Initialisierungsaufgaben speziell für Ihren Protokollhandler ausführen kann, z. B. das Überprüfen der URL für ein Element, auf das zugegriffen wird, oder das Überprüfen des Zeitpunkts der letzten Änderung, um festzustellen, ob eine Datei in der aktuellen Durchforstung verarbeitet werden muss.

Hinweis

Geänderte Zeiten für Verzeichnisse werden ignoriert. Das IUrlAccessor-Objekt muss die untergeordneten Objekte auflisten, um zu bestimmen, ob Änderungen oder Löschungen vorgenommen wurden.

 

Ein Großteil des Entwurfs des UrlAccessor-Objekts hängt davon ab, ob die Struktur hierarchisch oder linkbasiert ist. Für hierarchische Datenspeicher muss das UrlAccessor-Objekt einen Filter finden, der den Inhalt auflisten kann. Ein weiterer Unterschied zwischen hierarchischen und linkbasierten Protokollhandlern ist die Verwendung der IsDirectory-Methode. In linkbasierten Protokollhandlern sollte diese Methode S_FALSE zurückgeben. Hierarchische Protokollhandler müssen S_OK für Container zurückgeben.

Weitere Anweisungen zum Implementieren einer IUrlAccessor-Schnittstelle finden Sie in der Referenz zur IUrlAccessor-Schnittstelle .

IProtocolHandlerSite

Diese Schnittstelle wird verwendet, um ein SearchProtocol-Objekt zu instanziieren und stellt auch dem UrlAccessor-Objekt einen geeigneten Filter für eine angegebene Klassen-ID (CLSID) bereit.

IFilter für Container

Wenn Sie einen hierarchischen Protokollhandler implementieren, müssen Sie eine Container-IFilter-Komponenteimplementieren, die URLs aufzählt, die Container oder Ordner darstellen. Der Enumerationsprozess ist eine Schleife durch die GetChunk - und GetValue-Methoden der IFilter-Schnittstelle, die eine Liste von URLs zurückgeben, die jedes Element im Container darstellen.

Zunächst gibt GetChunk einen FULLPROSPEC-Wert zurück, wobei die Eigenschaft GATHER_PROPSET festgelegt ist, und entweder:

  • PID_GTHR_DIRLINK die URL zum Element ohne den Zeitpunkt der letzten Änderung, oder
  • PID_GTHR_DIRLINK_WITH_TIME die URL zusammen mit dem Zeitpunkt der letzten Änderung

Die Eigenschaftensatz-GUID für GATHER_PROPSET ist 0B63E343-9CCC-11D0-BCDB-00805FCCCE04. Die PROPSPEC-Eigenschaft ist entweder PID_GTHR_DIRLINK=2 oder PID_GTHR_DIRLINK_WITH_TIME = 12 Dezimalstellen.

Das Zurückgeben PID_GTHR_DIRLINK_WITH_TIME ist effizienter, da der Indexer sofort bestimmen kann, ob das Element indiziert werden muss, ohne die Methoden ISearchProtocol-CreateUrlAccessor>() und IUrlAccessor-GetLastModified>() aufzurufen.

GetValue gibt dann eine PROPVARIANT-Eigenschaft für die URL (und bei Verwendung der Uhrzeit der letzten Änderung) wie folgt zurück:

  • VT_LPWSTR die URL des untergeordneten Elements oder
  • Vektor der URL gefolgt von einer FILETIME

Der folgende Beispielcode veranschaulicht, wie Sie die richtige PID_GTHR_DIRLINK_WITH_TIME erstellen.

Hinweis

DIESER CODE UND DIE INFORMATIONEN WERDEN OHNE JEGLICHE AUSDRÜCKLICHE ODER STILLSCHWEIGENDE GEWÄHRLEISTUNG BEREITGESTELLT, EINSCHLIEßLICH, ABER NICHT BESCHRÄNKT AUF DIE STILLSCHWEIGENDEN GEWÄHRLEISTUNGEN DER HANDELSÜBLICHKEIT UND/ODER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.

Copyright (C) Microsoft. Alle Rechte vorbehalten.

 

// params are assumed to be valid

HRESULT GetPropVariantForUrlAndTime(PCWSTR pszUrl, const FILETIME &ftLastModified, PROPVARIANT **ppPropValue)
{
    *ppPropValue = NULL;

    // allocate the propvariant pointer
    *ppPropValue = (PROPVARIANT *)CoTaskMemAlloc(sizeof(*ppPropValue));
    HRESULT hr = *ppPropValue ? S_OK : E_OUTOFMEMORY;

    if (SUCCEEDED(hr))
    {
        PropVariantInit(*ppPropValue);  // zero init the value

        // now allocate enough memory for 2 nested PropVariants.
        // PID_GTHR_DIRLINK_WITH_TIME is an array of 2 PROPVARIANTs
        PROPVARIANT *pVector = (PROPVARIANT *)CoTaskMemAlloc(sizeof(*pVector) * 2);
        hr = pVector ? S_OK : E_OUTOFMEMORY;

        if (SUCCEEDED(hr))
        {
            // set the container PROPVARIANT that it is a vector of 2 PROPVARIANTS
            (*ppPropValue)->vt = VT_VARIANT | VT_VECTOR;
            (*ppPropValue)->capropvar.cElems = 2;
            (*ppPropValue)->capropvar.pElems = pVector;
            PWSTR pszUrlAlloc;
            hr = SHStrDup(pszUrl, &pszUrlAlloc);

            if (SUCCEEDED(hr))
            {
                // now fill the array of PROPVARIANTS
                // put the pointer to the URL into the vector
                (*ppPropValue)->capropvar.pElems[0].vt = VT_LPWSTR; 
                (*ppPropValue)->capropvar.pElems[0].pwszVal = pszUrlAlloc;

                 // put the FILETIME into vector
                (*ppPropValue)->capropvar.pElems[1].vt = VT_FILETIME; 
                (*ppPropValue)->capropvar.pElems[1].filetime = ftLastModified;
            }

            else
            {
                CoTaskMemFree(pVector);
            }
        }
 
        if (FAILED(hr))
        {
            CoTaskMemFree(*ppPropValue);
            *ppPropValue = NULL;
        }
    }
    return S_OK;
}

Hinweis

Eine IFilter-Containerkomponentesollte immer alle untergeordneten URLs aufzählen, auch wenn sich die untergeordneten URLs nicht geändert haben, da der Indexer Löschungen über den Enumerationsprozess erkennt. Wenn die Datumsausgabe in einem DIR_LINKS_WITH_TIME angibt, dass sich die Daten nicht geändert haben, aktualisiert der Indexer die Daten für diese URL nicht.

 

Die physische URL ist die URL, die vom UrlAccessor-Objekt verarbeitet wird. Wenn der Filter keine benutzerfreundliche DisplayUrl ausgibt, zeigt WDS dem Benutzer die physische URL als Teil der Suchergebnisse an. Das WDS-Schema enthält zwei Eigenschaften, um zu steuern, was dem Endbenutzer angezeigt wird, wie in der folgenden Tabelle dargestellt.

GUID PROPSPEC Beschreibung
D5CDD505-2E9C-101B-9397-08002B2CF9AE DisplayFolder Ordnerpfad, der dem Benutzer in den Suchergebnissen angezeigt wird
D5CDD505-2E9C-101B-9397-08002B2CF9AE FolderName Anzeigename des übergeordneten Ordners

 

Wenn Ihr Code keinen DisplayFolder oder FolderName ausgibt, werden diese Werte aus der DisplayUrl berechnet. Schrägstriche in der URL kennzeichnen Container im Speicher oder Dateisystem.

Hinzufügen von Protokollhandleroptionen

Damit Ihr Protokollhandler über eine Standardstartseite (und die Eingabeknoten-URL) verfügt, müssen Sie die ISearchProtocolOptions-Schnittstelle implementieren. In zukünftigen Versionen von WDS wird diese Schnittstelle Hooks zum Dialogfeld Optionen für eine verbesserte Benutzererfahrung bereitstellen. Diese Schnittstelle bietet die folgenden Funktionen:

  • Bestimmt, ob die Anforderungen für Ihren Protokollhandler erfüllt sind. Beispielsweise erfordert der Speicher Ihres Protokollhandlers möglicherweise Zugriff auf eine bestimmte Anwendung, um die Daten der Anwendung ordnungsgemäß indizieren zu können, aber diese Anwendung ist nicht verfügbar.
  • Gibt die Mindestanforderungen an, die ihr Protokollhandler zum Verarbeiten eines Elements benötigt. Anforderungen können in einer benutzerfreundlichen, lokalisierten Beschreibung ausgedrückt werden, z. B. "Microsoft Outlook 2000 oder höher".
  • Definiert die URLs, die der Protokollhandler standardmäßig verarbeiten soll.

ISearchProtocolOptions

In der folgenden Tabelle werden die Methoden beschrieben, die Sie für die ISearchProtocolOptions-Schnittstelle implementieren müssen.

Methode Beschreibung
CheckRerements Bestimmt, ob die Mindestanforderungen eines benutzerdefinierten Protokollhandlers erfüllt sind.
GetDefaultCrawlScope Gibt eine Liste der Standard-URLs in einem angegebenen Speicher für einen benutzerdefinierten Protokollhandler zurück.
GetRequirements Gibt eine benutzerfreundliche, lokalisierte Beschreibung der Mindestanforderungen für einen benutzerdefinierten Protokollhandler an.

 

Referenz

Benachrichtigen des Indexes der Änderungen

Hinzufügen von Symbolen, Vorschauen und Kontextmenüs mit Shellerweiterungen

Installieren und Registrieren von Protokollhandlern