Bewährte Methoden und häufig gestellte Fragen zu Eigenschaftenhandlern

In diesem Thema wird erläutert, wie Sie Eigenschaftenhandler für die Arbeit mit dem Windows-Eigenschaftensystem erstellen und registrieren.

Dieses Thema ist wie folgt organisiert:

Bewährte Methoden

Überschreiben von Dateisystemeigenschaften

Einige Eigenschaften für Dateien werden von der Dateisystemdatenquelle bereitgestellt, z. B.:

  • PKEY_FileName
  • PKEY_Extension
  • PKEY_ModifiedTime

Im Allgemeinen können Eigenschaftenhandler keine Werte für diese Eigenschaften bereitstellen. In einigen Fällen können diese Eigenschaften jedoch basierend auf den Registrierungsinformationen überschrieben werden, die vom Eigenschaftenhandler bereitgestellt werden. Eigenschaftenhandler füllen HKEY_CLASSES_ROOT\CLSID\{handler clsid}\OverrideFileSystemProperties mit den Namen der Eigenschaften auf, die sie überschreiben möchten. Dies ist auf einen festen Satz von Eigenschaften beschränkt, die in der folgenden Liste angezeigt werden, über die das System Kenntnis hat.

Das Überschreiben wird für die folgenden Eigenschaftswerte unterstützt:

Eine vollständige Liste aller Shell-Eigenschaften finden Sie unter Shelleigenschaften.

Wichtig

Die überschriebenen Eigenschaftswerte werden nur verwendet, wenn die Dateien indiziert werden. Daher werden beim Durchsuchen von Dateien aus der Dateisystemdatenquelle die überschriebenen Werte nicht angezeigt.  

Speichern von Eigenschaften in XML-basierten Dateiformaten

Es gibt zwei grundlegende Optionen zum Speichern von Eigenschaften in XML-basierten Dateiformaten:

  • Speichern Sie jede Eigenschaft mithilfe von XML-Elementen und -Attributen gemäß dem XML-Schema des Dokuments. Dieser Ansatz ist "XML-freundlicher".
  • Serialisieren Sie den gesamten Eigenschaftenspeicher in ein Binary Large Object (BLOB), konvertieren Sie das BLOB in eine base64-codierte Zeichenfolge, und speichern Sie diese Zeichenfolge dann im XML-Code. Dies ist der einfachere der beiden Ansätze und kann verwendet werden, um offene Metadaten zu unterstützen.

Einige Handler können diese Ansätze kombinieren, z. B. einige wichtige Werte im XML-Standardformat speichern und den Rest in einem BLOB speichern.

Berechnete Eigenschaften

Einige Eigenschaften werden von bestimmten Attributen einer Datei abgeleitet. Die System.Image.Dimensions-Eigenschaft wird beispielsweise durch die tatsächlichen Dimensionen des Bilds in einer Bilddatei bestimmt. Da solche Eigenschaftswerte vom Eigenschaftenhandler nicht geändert werden können, werden sie daher in der Eigenschaftenbeschreibung markiert isInnate="true" . Andere Eigenschaften werden aus einem Teil einer bestimmten Eigenschaft oder durch Aggregieren der Werte mehrerer Eigenschaften berechnet. Da Updates dieser "berechneten" Eigenschaften Mehrdeutigkeit darüber erzeugen würden, wie die Quellwerte geändert werden sollen, sollten berechnete Eigenschaften in der Eigenschaftenbeschreibung markiert isInnate="true" oder als schreibgeschützt gemeldet werden. Die letztere Option ist verfügbar, indem der Handler angewiesen wird, S_FALSE aus IPropertyStoreCapabilities::IsPropertyWritable zurückzugeben.

Häufig gestellte Fragen

Warum wird mein Eigenschaftenhandler nicht vom Windows Search-Indexer geladen?

Der Windows Search-Indexer wird als Systemdienst ausgeführt und kann keine DLLs laden, die im Benutzerprofilverzeichnis gespeichert sind. Wenn Sie mit Microsoft Visual Studio erstellen und debuggen, wird die DLL in Ihrem Benutzerprofil platziert (und wird daher nicht vom Indexer geladen). Um dies zu umgehen, kopieren Sie Ihre DLL außerhalb Ihres Profilordners (z. B. in C:\Programme\YourAppName), und registrieren Sie sie dort.

Ausführlichere Anleitungen zum Entwickeln von Eigenschaftenhandlern für die Arbeit mit dem Windows Search-Indexer finden Sie unter Entwickeln von Eigenschaftenhandlern für Windows Search.

Welche Eigenschaften sollten mit den Enumerationsmethoden "IPropertyStore::GetCount" und "IPropertyStore::GetAt" ermittelt werden können?

Nicht alle Clients von Eigenschaftenspeicherobjekten verwenden diese Methoden. Einige Clients kennen die Eigenschaften, die sie direkt anfordern möchten (nach PKEY-Name), oder erhalten Eigenschafteninformationen über eine Eigenschaftenbeschreibungsliste. Die Methoden zur Eigenschaftenermittlung ermöglichen mehrere andere Szenarien. Wenn eine Eigenschaft an diesen Szenarien nicht teilnehmen muss, muss sie nicht aufgelistet werden. Daher kann ein Eigenschaftenhandler einen nicht VT_EMPTY Wert für Eigenschaften erzeugen, die nicht über die Methoden IPropertyStore::GetCount und IPropertyStore::GetAt ermittelt werden.

Eigenschaften sollten jedoch über diese Methoden sichtbar sein, wenn eine der folgenden Bedingungen erfüllt ist:

  • Wenn die Eigenschaft so indiziert ist, dass sie durchsuchbar ist: Dies bedeutet, dass es im Windows Search-Eigenschaftenspeicher enthalten ist (als im Eigenschaftenbeschreibungsschema bezeichnet isColumn = "true" ) oder für Volltextsuchen verfügbar ist (inInvertedIndex = "true"). Wenn diese Flags fehlen oder keine Eigenschaftenbeschreibung vorhanden ist, werden Eigenschaften vom Typ "string" automatisch dem invertierten Index hinzugefügt, um die Suche zu ermöglichen. Da die Liste der bekannten Eigenschaften (mit installierten Eigenschaftenbeschreibungen) im Eigenschaftensystem sehr groß ist (mehr als 800 Eigenschaften), wäre es unpraktisch, jeden Eigenschaftenhandler für jede im Eigenschaftensystem registrierte Eigenschaft zu fragen. Stattdessen listet der Indizierungsprozess die relevanten Eigenschaften aus dem Eigenschaftenhandler für jedes Element auf, das er indiziert, und verwendet die Werte der aufgezählten Eigenschaften, um den Volltextindex zu erstellen.
  • Wenn die Eigenschaft kopiert werden soll, wenn der Eigenschaftssatz des Elements dupliziert wird: Um eine Funktion zum Kopieren eines Eigenschaftensatzes zu implementieren, macht das Quellelement die Eigenschaften sichtbar, die über die Methoden IPropertyStore::GetCount und IPropertyStore::GetAt kopiert werden sollen. Eigenschaften, die nicht kopiert werden müssen oder nicht sinnvoll sind, kopiert zu werden, sollten nicht eingeschlossen werden.
  • Wenn der Eigenschaftswert nicht leer ist (VT_EMPTY): Eigenschaftswerte, die leer sind, sind für Clients nicht nützlich. Wenn Clients versuchen, leere Eigenschaftswerte zurückzugeben, wird der Wert VT_EMPTY zurückgegeben. Daher sollten Eigenschaften mit leeren Werten nicht aufgelistet werden.
  • Wenn die Eigenschaft beim Aufrufen der Funktion "Eigenschaften entfernen" entfernt werden soll: Dieses Feature ist zum Schutz der Privatsphäre vorhanden. Es ermittelt alle Werte aus dem Eigenschaftenhandler über eine Enumeration und entfernt alle Werte, die vom Benutzer zum Entfernen ausgewählt wurden.

Hinweis

Das Aufzählen von Eigenschaften kommuniziert nicht den Satz von Eigenschaften, die ein bestimmter Eigenschaftenhandler unterstützt, wenn der Handler ein festes Schema (und keine geöffneten Metadaten) unterstützt. Stattdessen sollten solche Handler den Satz von Eigenschaften dokumentieren, die sie unterstützen.

 

Gewusst wie wissen, welche Dateiformate offene Metadaten unterstützen?

Informationen zur Unterstützung für offene Metadaten finden Sie unter Dateitypen, die offene Metadaten unterstützen.

Können VT_NULL Werte mithilfe eines Eigenschaftenhandlers gespeichert werden?

Nein. VT_NULL Werte werden bei Aufrufen von IPropertyStore::GetValue und IPropertyStore::SetValue in VT_EMPTY konvertiert.

Welche Datumszeichenfolgenformate werden von der Funktion "PropVariantChangeType" unterstützt?

Im Allgemeinen sollten Eigenschaften, die Datums-/Uhrzeitwerte darstellen, mithilfe von VT_FILETIME dargestellt werden. Viele Datenquellen stellen diese Informationen jedoch in Zeichenfolgenform bereit. Die PropVariantChangeType-Hilfs-API unterstützt das Coercing einiger Zeichenfolgendatumsformate in FILETIME-Werte , wie in der folgenden Tabelle gezeigt.

Format Windows Vista, Windows XP und Microsoft Windows Desktop Search (WDS) Windows 7 Hinweise
jjjj/mm/tt:hh:mm:ss.uuu Ja Ja UTC; y=year, m=month, d=date, h=hours (24-Stunden-Uhr), m=minuten, s=sekunden, u=microseconds
jjjj-mm-ttThh:mm:ssZ Nein Ja ISO8601-Formatspezifikation UTC (wird mit dem Zeitzonenindikator "Z" bezeichnet); y=year, m=month, d=date, h=hours (24-Stunden-Uhr), m=minuten, s=sekunden; "T" ist ein Trennzeichen für den Zeitteil.

Ist es möglich, einen schreibgeschützten Eigenschaftenhandler zu erstellen?

Ja. Einige Eigenschaftenhandlerimplementierungen unterstützen das Schreiben von Eigenschaftswerten nicht. Diese Eigenschaftenhandler sollten STGM_E_ACCESSDENIED bei Aufrufen von IInitializeXXX::Initialize zurückgeben, die STGM_READWRITE übergeben, oder bei jedem Aufruf von IPropertyStore::SetValue.

Alle Eigenschaftenhandler, die im STGM_READ Modus geöffnet werden, sollten STGM_E_ACCESSDENIED bei Aufrufen von IPropertyStore::SetValue zurückgeben.

Kann ein Eigenschaftenhandler eine Eigenschaft als schreibgeschützt behandeln, auch wenn das Schema angibt, dass die Eigenschaft schreibbar ist?

Ja. Im Schemasystem werden Eigenschaften als schreibgeschützt (einschließlich der eigenschaften mit isInnate = "true") oder als lese-/schreibgeschützt gekennzeichnet. Eigenschaftenhandler, die das Schreiben einer bestimmten Eigenschaft, die laut Schema schreibbar sein soll, nicht unterstützen, sollten IPropertyStoreCapabilities implementieren und S_FALSE bei Aufrufen von IPropertyStoreCapabilities::IsPropertyWritable für diese Eigenschaft zurückgeben. Dies gibt an, dass die Eigenschaft im Kontext dieses Handlers und dieser Datei nicht schreibbar ist.

Hinweis

Die umgekehrte Aktion ist nicht möglich. Sie können einen Eigenschaftenhandler nicht aktivieren, um eine Eigenschaft zu schreiben, die im Schema als schreibgeschützt markiert ist.