Framework-Eigenschaftenmetadaten

Artikel
08/20/2008

Aktualisiert: November 2007

Framework-Eigenschaftenmetadaten werden für die Eigenschaften von Objektelementen berichtet, die sich auf der WPF-Frameworkebene der Windows Presentation Foundation (WPF)-Architektur befinden. Normalerweise führt die Bezeichnung WPF-Frameworkebene dazu, dass Funktionen wie Rendering, Datenbindung und Anpassungen des Eigenschaftensystems von der WPF-Präsentations-APIs und den entsprechenden ausführbaren Dateien verarbeitet werden. Framework-Eigenschaftenmetadaten werden von diesen Systemen abgefragt, um funktionsspezifische Merkmale bestimmter Elementeigenschaften zu ermitteln.

Dieses Thema enthält folgende Abschnitte.

Vorbereitungsmaßnahmen
Was wird von den Framework-Eigenschaftenmetadaten übermittelt?
Lesen von FrameworkPropertyMetadata
Angeben von Metadaten
Zusammenführungsverhalten von Framework-Eigenschaftenmetadaten
Verwandte Abschnitte

Vorbereitungsmaßnahmen

In diesem Thema wird vorausgesetzt, dass Sie sich mit Abhängigkeitseigenschaften aus Sicht eines Consumers vorhandener Abhängigkeitseigenschaften über Windows Presentation Foundation (WPF)-Klassen auskennen und dass Sie die Übersicht über Abhängigkeitseigenschaften gelesen haben. Sie sollten außerdem den Abschnitt Metadaten für Abhängigkeitseigenschaften gelesen haben.

Was wird von den Framework-Eigenschaftenmetadaten übermittelt?

Framework-Eigenschaftenmetadaten können in die folgenden Kategorien unterteilt werden:

Berichten von Layouteigenschaften, die sich auf ein Element auswirken (AffectsArrange, AffectsMeasure, AffectsRender). Sie können diese Flags bei Bedarf in den Metadaten setzen, wenn sich die Eigenschaft auf diese Aspekte auswirkt und wenn Sie außerdem die Methoden MeasureOverride / ArrangeOverride in Ihrer Klasse implementieren, um für das Layoutsystem ein bestimmtes Renderingverhalten und entsprechende Informationen bereitzustellen. Normalerweise führt eine Implementierung dieser Art eine Prüfung auf Ungültigkeitserklärungen von Eigenschaften in Abhängigkeitseigenschaften durch, für die beliebige dieser Layouteigenschaften in den Eigenschaftenmetadaten wahr sind. Nur diese Ungültigkeiten erfordern dann die Anforderung eines neuen Layoutdurchlaufs.
Melden von Layouteigenschaften, die sich auf das übergeordnete Element eines Elements auswirken (AffectsParentArrange, AffectsParentMeasure). Beispiele für Fälle, in denen diese Flags standardmäßig festgelegt sind, sind FixedPage.Left und Paragraph.KeepWithNext.
Inherits. Standardmäßig erben Abhängigkeitseigenschaften keine Werte. Mithilfe von OverridesInheritanceBehavior kann der Kommunikationsweg der Vererbung auch durch eine visuelle Struktur verlaufen. Dies ist für einige Szenarios der Steuerelementzusammenstellung erforderlich.

Tipp

Der Ausdruck "erben" hat im Zusammenhang mit Eigenschaftenwerten für Abhängigkeitseigenschaften eine besondere Bedeutung. Er bedeutet, dass untergeordnete Elemente von übergeordneten Elementen den Wert der Abhängigkeitseigenschaft erben können. Dies ist mithilfe einer Funktion der WPF-Frameworkebene des WPF-Eigenschaftensystems möglich. Dabei besteht kein direkter Zusammenhang mit verwalteten Codetypen und mit der Membervererbung über abgeleitete Typen. Ausführliche Informationen finden Sie unter Vererbung von Eigenschaftenwerten.
Berichten von Datenbindungsmerkmalen (IsNotDataBindable, BindsTwoWayByDefault). Standardmäßig handelt es sich um Abhängigkeitseigenschaften in der Frameworkunterstützungs-Datenbindung mit einem unidirektionalen Bindungsverhalten. Sie könnten die Datenbindung deaktivieren, wenn dafür kein Szenario vorhanden wäre (da diese Elemente flexibel und erweiterbar gestaltet sind, enthält die standardmäßige WPF-APIs nicht viele Beispiele hierfür). Sie können die Bindung so einrichten, dass sie einen bidirektionalen Standard für Eigenschaften verwendet, die die Verhalten eines Steuerelements mithilfe seiner Komponententeile zusammenhalten (Beispiel: IsSubmenuOpen), oder dass die bidirektionale Bindung das gängige und erwartete Szenario für Benutzer ist (Beispiel: Text). Eine Änderung der für die Datenbindung relevanten Metadaten wirkt sich nur auf die Standardeinstellung aus. Diese Standardeinstellung kann pro Bindung jeweils individuell geändert werden. Ausführliche Informationen zu den Bindungsmodi und zur Bindung im Allgemeinen finden Sie unter Übersicht über Datenbindung.
Berichten, ob Eigenschaften von Anwendungen oder Diensten in ein Journal eingetragen werden sollten, die diese Funktion unterstützen (Journal). Für allgemeine Elemente ist die Journalfunktion standardmäßig nicht aktiviert, aber sie kann für bestimmte Benutzereingabe-Steuerelemente bedarfsabhängig aktiviert werden. Diese Eigenschaft soll von Journaldiensten gelesen werden, einschließlich der entsprechenden WPF-Implementierung, und wird in der Regel für Benutzersteuerelemente eingerichtet, z. B. Auswahlmöglichkeiten in Listen, die über mehrere Navigationsschritte hinweg beibehalten werden sollen. Informationen zum Journal finden Sie unter Übersicht über die Navigation.

Lesen von FrameworkPropertyMetadata

Bei allen oben mit Link angegebenen Eigenschaften handelt es sich um die spezifischen Eigenschaften, die die FrameworkPropertyMetadata den direkten Basisklassen-UIPropertyMetadata hinzufügt. Jede dieser Eigenschaften ist standardmäßig false. Eine Metadatenanforderung für eine Eigenschaft, bei der es wichtig ist, dass der Wert dieser Eigenschaften bekannt ist, sollte versuchen, die zurückgegebenen Metadaten in FrameworkPropertyMetadata umzuwandeln. Anschließend sollten je nach Bedarf die Werte der einzelnen Eigenschaften überprüft werden.

Angeben von Metadaten

Wenn Sie eine neue Metadateninstanz erstellen, um Metadaten auf eine neue Registrierung einer Abhängigkeitseigenschaft anzuwenden, können Sie wählen, welche Metadatenklasse Sie verwenden: die PropertyMetadata-Basisversion oder eine abgeleitete Klasse wie FrameworkPropertyMetadata. Im Normalfall sollten Sie FrameworkPropertyMetadata verwenden, besonders dann, wenn Ihre Eigenschaft über eine Interaktion mit Eigenschaftensystem- und WPF-Funktionen verfügt, z. B. in Verbindung mit Layout und Datenbindung. Eine weitere Möglichkeit, anspruchsvollere Szenarios zu verwenden, ist die Ableitung von FrameworkPropertyMetadata, um Ihre eigene Klasse zum Melden von Metadaten zu erstellen, wobei die Member über zusätzliche Informationen verfügen. Sie können auch PropertyMetadata oder UIPropertyMetadata verwenden, um den Unterstützungsgrad für Funktionen Ihrer Implementierung zu kommunizieren.

Für vorhandene Eigenschaften (AddOwner- oder OverrideMetadata-Aufruf) sollten Sie stets eine Überschreibung mit dem Metadatentyp durchführen, der von der ursprünglichen Registrierung verwendet wird.

Wenn Sie eine FrameworkPropertyMetadata-Instanz erstellen, haben Sie zwei Möglichkeiten, diese Metadaten mit Werten für die spezifischen Eigenschaften zu füllen, die die Framework-Eigenschaftenmerkmale kommunizieren:

Verwenden Sie die FrameworkPropertyMetadata-Konstruktorsignatur, die einen flags-Parameter zulässt. Dieser Parameter sollte mit allen gewünschten kombinierten Werten der FrameworkPropertyMetadataOptions-Enumerationsflags gefüllt werden.
Verwenden Sie eine der Signaturen ohne flags-Parameter, und setzen Sie dann alle berichtenden booleschen Eigenschaften unter FrameworkPropertyMetadata für die einzelnen gewünschten Merkmalsänderungen auf true. Wenn Sie dies durchführen, müssen Sie diese Eigenschaften festlegen, bevor Elemente mit dieser Abhängigkeitseigenschaft erstellt werden. Die booleschen Eigenschaften verfügen über Schreib-/Lesezugriff, damit dieses Verhalten die Verwendung des flags-Parameters vermeiden, die Metadaten jedoch trotzdem füllen kann. Die Metadaten müssen vor der Verwendung der Eigenschaften jedoch richtig versiegelt werden. Der Versuch, die Eigenschaften festzulegen, nachdem die Metadaten angefordert wurden, ist somit ein ungültiger Vorgang.

Zusammenführungsverhalten von Framework-Eigenschaftenmetadaten

Wenn Sie Framework-Eigenschaftenmetadaten überschreiben, werden die einzelnen Metadatenmerkmale entweder zusammengeführt oder ersetzt.

PropertyChangedCallback wird zusammengeführt. Wenn Sie einen neuen PropertyChangedCallback hinzufügen, wird dieser Rückruf in den Metadaten gespeichert. Wenn Sie in der Überschreibung keinen PropertyChangedCallback angeben, wird der Wert von PropertyChangedCallback als Verweis des nächsten Vorgängers höher gestuft, der diesen in den Metadaten angegeben hat.
Das eigentliche Verhalten des Eigenschaftensystems für PropertyChangedCallback besteht darin, dass Implementierungen für alle Metadatenbesitzer in der Hierarchie beibehalten und der Tabelle hinzugefügt werden. Für das Eigenschaftensystem gilt die Ausführungsreihenfolge, dass Rückrufe der am stärksten abgeleiteten Klasse zuerst aufgerufen werden. Geerbte Rückrufe werden nur einmal ausgeführt. Sie werden als Eigentum der Klasse angesehen, die sie in die Metadaten eingefügt hat.
DefaultValue wird ersetzt. Wenn Sie in der Überschreibung keinen PropertyChangedCallback angeben, stammt der Wert von DefaultValue vom nächsten Vorgänger, der diesen in den Metadaten angegeben hat.
CoerceValueCallback-Implementierungen werden ersetzt. Wenn Sie einen neuen CoerceValueCallback hinzufügen, wird dieser Rückruf in den Metadaten gespeichert. Wenn Sie in der Überschreibung keinen CoerceValueCallback angeben, wird der Wert von CoerceValueCallback als Verweis des nächsten Vorgängers höher gestuft, der diesen in den Metadaten angegeben hat.
Das Verhalten des Eigenschaftensystems besteht darin, dass nur der CoerceValueCallback in den unmittelbaren Metadaten aufgerufen wird. Es werden keine Verweise auf andere CoerceValueCallback-Implementierungen in der Hierarchie beibehalten.
Die Flags von FrameworkPropertyMetadataOptions werden als bitweiser Vorgang oder normaler Vorgang kombiniert, im Gegensatz zu den verschiedenen äquivalenten booleschen Eigenschaftenwerten im FrameworkPropertyMetadata-Element der geerbten Metadaten. IsAnimationProhibited wird durch einen beliebigen neuen Wert ersetzt, oder es wird der Wert aus den geerbten Metadaten weitergegeben.