Benutzerdefinierte Abhängigkeitseigenschaften

Aktualisiert: November 2007

In diesem Thema sind die Gründe beschrieben, aus denen Windows Presentation Foundation (WPF)-Anwendungs- und Komponentenentwickler ggf. benutzerdefinierte Abhängigkeitseigenschaften erstellen. Außerdem werden die Implementierungsschritte und einige Implementierungsoptionen beschrieben, mit denen Sie die Leistung, die Verwendbarkeit oder die Vielseitigkeit der Eigenschaft verbessern können.

Dieses Thema enthält folgende Abschnitte.

• Vorbereitungsmaßnahmen
• Was ist eine Abhängigkeitseigenschaft?
• Beispiele für Abhängigkeitseigenschaften
• Wann sollten Sie eine Abhängigkeitseigenschaft implementieren?
• Prüfliste für die Definition einer Abhängigkeitseigenschaft
• Schreibgeschützte Abhängigkeitseigenschaften
• Abhängigkeitseigenschaften vom Typ "Auflistung"
• Sicherheitsüberlegungen für Abhängigkeitseigenschaften
• Abhängigkeitseigenschaften und Klassenkonstruktoren
• Verwandte Abschnitte

Vorbereitungsmaßnahmen

In diesem Thema wird vorausgesetzt, dass Sie sich mit Abhängigkeitseigenschaften aus Sicht eines Consumers vorhandener Abhängigkeitseigenschaften in WPF-Klassen auskennen und das Thema Übersicht über Abhängigkeitseigenschaften gelesen haben. Um den Beispielen in diesem Thema folgen zu können, sollten Sie außerdem mit der Verwendung von Extensible Application Markup Language (XAML) und dem Schreiben von WPF-Anwendungen vertraut sein.

Was ist eine Abhängigkeitseigenschaft?

Sie können eine common language runtime (CLR)-Eigenschaft so aktivieren, dass sie Stile, Datenbindung, Vererbung, Animationen und Standardwerte unterstützt, indem Sie die Eigenschaft als Abhängigkeitseigenschaft implementieren. Bei Abhängigkeitseigenschaften handelt es sich um Eigenschaften, die im WPF-Eigenschaftensystem registriert werden, indem die Register-Methode (oder RegisterReadOnly) aufgerufen wird, und die als Unterstützung über ein DependencyProperty-Bezeichnerfeld verfügen. Abhängigkeitseigenschaften können nur von DependencyObject-Typen verwendet werden, aber das DependencyObject ist in der WPF-Klassenhierarchie ziemlich weit oben angeordnet, so dass die Mehrzahl der in WPF verfügbaren Klassen Abhängigkeitseigenschaften unterstützen kann. Weitere Informationen zu Abhängigkeitseigenschaften und zur Terminologie und den dazugehörigen Konventionen, die in diesem SDK verwendet werden, finden Sie unter Übersicht über Abhängigkeitseigenschaften.

Beispiele für Abhängigkeitseigenschaften

Beispiele für Abhängigkeitseigenschaften, die für WPF-Klassen implementiert werden, sind u. a. die Background-Eigenschaft, die Width-Eigenschaft und die Text-Eigenschaft. Jede Abhängigkeitseigenschaft, die von einer Klasse offengelegt wird, verfügt über ein entsprechendes öffentliches, statisches Feld vom Typ DependencyProperty, das für dieselbe Klasse offengelegt wird. Dies ist der Bezeichner der Abhängigkeitseigenschaft. Für die Benennung des Bezeichners wird eine Konvention verwendet: der Name der Abhängigkeitseigenschaft mit der angehängten Zeichenfolge Property. Zum Beispiel lautet das entsprechende DependencyProperty-Bezeichnerfeld für die Background-Eigenschaft BackgroundProperty. Der Bezeichner speichert die Informationen zur Abhängigkeitseigenschaft, die bei der Registrierung gelten. Anschließend wird der Bezeichner dann für andere Vorgänge verwendet, die die Abhängigkeitseigenschaft betreffen, z. B. das Aufrufen von SetValue.

Wie in der Übersicht über Abhängigkeitseigenschaften erwähnt, sind alle Abhängigkeitseigenschaften in WPF (mit Ausnahme der meisten angefügten Eigenschaften) aufgrund der Wrapperimplementierung auch CLR-Eigenschaften. Daher können Sie Abhängigkeitseigenschaften per Code abrufen oder festlegen, indem Sie CLR-Accessoren aufrufen, die die Wrapper auf dieselbe Weise wie andere CLR-Eigenschaften definieren. Als Consumer eingerichteter Abhängigkeitseigenschaften verwenden Sie die DependencyObject-Methoden GetValue und SetValue, die den Verbindungspunkt zum zugrunde liegenden Eigenschaftensystem bilden, normalerweise nicht. Stattdessen hat die vorhandene Implementierung der CLR-Eigenschaften GetValue und SetValue bereits innerhalb der get- und set-Wrapperimplementierungen der Eigenschaft aufgerufen, so dass das Bezeichnerfeld richtig verwendet wird. Wenn Sie eine benutzerdefinierte Abhängigkeitseigenschaft selbst implementieren, definieren Sie den Wrapper auf ähnliche Weise.

Wann sollten Sie eine Abhängigkeitseigenschaft implementieren?

Beim Implementieren einer Eigenschaft für eine Klasse können Sie, sofern Ihre Klasse von DependencyObject abgeleitet ist, die Eigenschaft mit einem DependencyProperty-Bezeichner versehen und diese zu einer Abhängigkeitseigenschaft machen. Es ist nicht in allen Fällen erforderlich oder passend, dass eine Eigenschaft eine Abhängigkeitseigenschaft ist. Dies hängt von den Anforderungen des jeweiligen Szenarios ab. Manchmal reicht das typische Verfahren aus, bei dem die Eigenschaft als Unterstützung mit einem privaten Feld versehen wird. Sie sollten Ihre Eigenschaft jedoch stets als Abhängigkeitseigenschaft implementieren, wenn die Eigenschaft eine oder mehrere der folgenden WPF-Funktionen unterstützen soll:

• Sie möchten, dass für die Eigenschaft ein Stil festgelegt werden kann. Weitere Informationen finden Sie unter Erstellen von Formaten und Vorlagen.

• Sie möchten, dass die Eigenschaft die Datenbindung unterstützt. Weitere Informationen zur Datenbindung für Abhängigkeitseigenschaften finden Sie unter Gewusst wie: Binden der Eigenschaften von zwei Steuerelementen.

• Sie möchten, dass für die Eigenschaft ein dynamischer Ressourcenverweis festgelegt werden kann. Weitere Informationen finden Sie unter Übersicht über Ressourcen.

• Sie möchten, dass ein Eigenschaftenwert von einem übergeordneten Element in der Elementstruktur automatisch geerbt wird. Führen Sie die Registrierung in diesem Fall mit der RegisterAttached-Methode auch dann durch, wenn Sie für den CLR-Zugriff einen Eigenschaftenwrapper erstellen. Weitere Informationen finden Sie unter Vererbung von Eigenschaftenwerten.

• Sie möchten, dass die Eigenschaft animiert werden kann. Weitere Informationen finden Sie unter Übersicht über Animationen.

• Sie möchten, dass das Eigenschaftensystem es meldet, wenn sich der vorherige Wert der Eigenschaft aufgrund von Aktionen geändert hat, die das Eigenschaftensystem, die Umgebung oder der Benutzer ausgeführt hat, oder indem Stile gelesen und verwendet wurden. Mithilfe von Eigenschaftenmetadaten kann Ihre Eigenschaft eine Rückrufmethode angeben, die jeweils aufgerufen wird, wenn das Eigenschaftensystem ermittelt hat, dass sich der Eigenschaftenwert definitiv geändert hat. Ein verwandter Begriff ist die Koersion des Eigenschaftenwerts. Weitere Informationen finden Sie unter Rückrufe und Validierung von Abhängigkeitseigenschaften.

• Sie möchten geltende Metadatenkonventionen verwenden, die auch von WPF-Prozessen verwendet werden, z. B. das Berichten, ob es beim Ändern eines Eigenschaftenwerts erforderlich sein soll, dass das Layoutsystem die visuellen Objekte für ein Element neu zusammenstellt. Oder Sie möchten Metadatenüberschreibungen verwenden können, damit abgeleitete Klassen auf Metadaten basierende Merkmale wie den Standardwert ändern können.

• Sie möchten, dass die Eigenschaften eines benutzerdefinierten Steuerelements die Visual Studio 2008-WPF-Designer-Unterstützung erhalten, z. B. die Bearbeitung im Fenster Eigenschaften. Weitere Informationen finden Sie unter Übersicht über das Erstellen von Steuerelementen.

Bei diesen Szenarios sollten Sie auch prüfen, ob Sie Ihr Ziel erreichen können, indem Sie die Metadaten einer vorhandenen Abhängigkeitseigenschaft überschreiben, anstatt eine völlig neue Eigenschaft zu implementieren. Ob eine Metadatenüberschreibung ratsam ist, hängt von Ihrem Szenario und davon ab, inwieweit das Szenario der Implementierung in vorhandenen WPF-Abhängigkeitseigenschaften und -Klassen ähnelt. Weitere Informationen zum Überschreiben von Metadaten vorhandener Eigenschaften finden Sie unter Metadaten für Abhängigkeitseigenschaften.

Prüfliste für die Definition einer Abhängigkeitseigenschaft

Das Definieren einer Abhängigkeitseigenschaft umfasst vier unterschiedliche Begriffe bzw. Schritte. Bei diesen Begriffen handelt es sich nicht um zwingend erforderliche einzelne Schritte, da einige Schritte bei der Implementierung im Code in einzelnen Codezeilen zusammengefasst werden:

• (Optional) Erstellen Sie Eigenschaftenmetadaten für die Abhängigkeitseigenschaft.

• Registrieren Sie den Eigenschaftennamen im Eigenschaftensystem, indem Sie einen Besitzertyp und den Typ des Eigenschaftenwerts angeben. Geben Sie auch die Eigenschaftenmetadaten an, falls diese verwendet werden.

• Definieren Sie einen DependencyProperty-Bezeichner als publicstaticreadonly-Feld für den Besitzertyp.

• Definieren Sie eine CLR-Wrappereigenschaft, deren Name dem Namen der Abhängigkeitseigenschaft entspricht. Implementieren Sie den get-Accessor und den set-Accessor der CLR-Wrappereigenschaft, um eine Verbindung zu der Abhängigkeitseigenschaft herzustellen, die sie unterstützt.

Registrieren der Eigenschaft im Eigenschaftensystem

Damit Ihre Eigenschaft zu einer Abhängigkeitseigenschaft wird, müssen Sie die Eigenschaft in einer Tabelle registrieren, die vom Eigenschaftensystem verwaltet wird. Außerdem müssen Sie der Eigenschaft einen eindeutigen Bezeichner zuweisen, der bei späteren Vorgängen des Eigenschaftensystems als Qualifizierer verwendet wird. Bei diesen Vorgängen kann es sich um interne Vorgänge oder um Ihre eigenen APIs handeln, die Codeaufrufe durchführen. Um die Eigenschaft zu registrieren, rufen Sie die Register-Methode im Text Ihrer Klasse auf (innerhalb der Klasse, aber außerhalb von Memberdefinitionen). Das Bezeichnerfeld wird auch vom Register-Methodenaufruf als Rückgabewert bereitgestellt. Der Register-Aufruf erfolgt außerhalb von anderen Memberdefinitionen, weil Sie diesen Rückgabewert verwenden, um als Teil der Klasse ein public static readonly-Feld vom Typ DependencyProperty zuzuweisen und zu erstellen. Dieses Feld wird zum Bezeichner für die Abhängigkeitseigenschaft.

public static readonly DependencyProperty AquariumGraphicProperty = DependencyProperty.Register(
  "AquariumGraphic",
  typeof(Uri),
  typeof(AquariumObject),
  new FrameworkPropertyMetadata(null,
      FrameworkPropertyMetadataOptions.AffectsRender, 
      new PropertyChangedCallback(OnUriChanged)
  )
);

Namenskonventionen für Abhängigkeitseigenschaften

Für Abhängigkeitseigenschaften gelten Namenskonventionen, die Sie bis auf bestimmte Ausnahmefälle befolgen müssen.

Die Abhängigkeitseigenschaft selbst hat einen Hauptnamen (in diesem Beispiel "AquariumGraphic"), der als erster Parameter von Register angegeben wird. Dieser Name muss innerhalb eines Registrierungstyps eindeutig sein. Für Abhängigkeitseigenschaften, die über Basistypen geerbt werden, gilt, dass sie bereits Teil des Registrierungstyps sind. Die Namen von geerbten Eigenschaften können nicht erneut registriert werden. Es gibt jedoch ein Verfahren zum Hinzufügen einer Klasse als Besitzer einer Abhängigkeitseigenschaft, das Sie auch dann verwenden können, wenn die Abhängigkeitseigenschaft nicht geerbt wird. Ausführliche Informationen finden Sie unter Metadaten für Abhängigkeitseigenschaften.

Benennen Sie dieses Feld beim Erstellen des Bezeichnerfelds mit dem Namen der Eigenschaft, unter dem diese registriert wurde, und hängen Sie das Suffix Property an. Dieses Feld ist Ihr Bezeichner für die Abhängigkeitseigenschaft, der später als Eingabe für die Aufrufe SetValue und GetValue verwendet wird, die Sie in den Wrappern durchführen. Außerdem wird der Bezeichner für Ihre anderen Codezugriffe auf die Eigenschaft, für externe Codezugriffe, die Sie zulassen, für das Eigenschaftensystem und ggf. von XAML-Prozessoren verwendet.

Implementieren des Wrappers

Ihre Wrapperimplementierung sollte GetValue in der get-Implementierung und SetValue in der set-Implementierung aufrufen (um dies zu verdeutlichen, werden hier der ursprüngliche Registrierungsaufruf und das dazugehörige Feld dargestellt).

Von Ausnahmefällen abgesehen, sollten Ihre Wrapperimplementierungen jeweils nur die Aktion GetValue bzw. SetValue ausführen. Der Grund dafür wird im Thema Laden von XAML und Abhängigkeitseigenschaften erläutert.

Alle vorhandenen öffentlichen Abhängigkeitseigenschaften, die über WPF-Klassen bereitgestellt werden, verwenden dieses einfache Modell zur Wrapperimplementierung. Die meisten komplexen Schritte der Funktionsweise von Abhängigkeitseigenschaften sind entweder Teil eines Verhaltens des Eigenschaftensystems, oder sie werden mithilfe von anderen Maßnahmen wie Koersion oder Rückrufen bei Eigenschaftenänderungen über Eigenschaftenmetadaten implementiert.

public static readonly DependencyProperty AquariumGraphicProperty = DependencyProperty.Register(
  "AquariumGraphic",
  typeof(Uri),
  typeof(AquariumObject),
  new FrameworkPropertyMetadata(null,
      FrameworkPropertyMetadataOptions.AffectsRender, 
      new PropertyChangedCallback(OnUriChanged)
  )
);
public Uri AquariumGraphic
{
  get { return (Uri)GetValue(AquariumGraphicProperty); }
  set { SetValue(AquariumGraphicProperty, value); }
}

Der Konvention nach muss der Name der Wrappereigenschaft wieder dem Namen entsprechen, der als erster Parameter des Register-Aufrufs gewählt bzw. angegeben wurde, über den die Eigenschaft registriert wurde. Wenn Sie die Konvention für die Eigenschaft nicht befolgen, werden nicht zwangsläufig alle Verwendungsmöglichkeiten deaktiviert, aber Sie müssen einige wichtige Punkte beachten:

• Bestimmte Aspekte von Stilen und Vorlagen funktionieren nicht.

• Die meisten Tools und Designer müssen sich auf die Namenskonventionen verlassen können, um XAML richtig serialisieren zu können oder um die Entwurfsumgebungsunterstützung für Eigenschaften individuell bereitstellen zu können.

• Die aktuelle Implementierung des WPF-XAML-Ladeprogramms umgeht die Wrapper vollständig und verlässt sich beim Verarbeiten von Attributwerten auf die Namenskonvention. Weitere Informationen finden Sie unter Laden von XAML und Abhängigkeitseigenschaften.

Eigenschaftenmetadaten für eine neue Abhängigkeitseigenschaft

Wenn Sie eine Abhängigkeitseigenschaft registrieren, wird bei der Registrierung über das Eigenschaftensystem ein Metadatenobjekt erstellt, das die Eigenschaftenmerkmale speichert. Viele dieser Merkmale verfügen über Standardwerte, die festgelegt werden, wenn die Eigenschaft mit den einfachen Signaturen von Register registriert wird. Mithilfe von anderen Signaturen von Register können Sie beim Registrieren der Eigenschaft die gewünschten Metadaten angeben. Die häufigste Art von Metadaten, die für Abhängigkeitseigenschaften angegeben werden, ist ein Standardwert, der auf neue Instanzen angewendet wird, die die Eigenschaft verwenden.

Wenn Sie eine Abhängigkeitseigenschaft erstellen, die für eine abgeleitete Klasse von FrameworkElement vorhanden ist, können Sie die speziellere Metadatenklasse FrameworkPropertyMetadata verwenden, anstatt die PropertyMetadata-Basisklasse. Der Konstruktor für die FrameworkPropertyMetadata-Klasse hat mehrere Signaturen, mit deren Hilfe Sie verschiedene Metadatenmerkmale kombinieren können. Wenn Sie nur den Standardwert angeben möchten, verwenden Sie die Signatur, die einen einzelnen Parameter vom Typ Object erfordert. Übergeben Sie diesen Objektparameter als typspezifischen Standardwert für Ihre Eigenschaft (der angegebene Standardwert muss den Typ aufweisen, den Sie als propertyType-Parameter im Register-Aufruf angegeben haben).

Bei Verwendung von FrameworkPropertyMetadata können Sie für die Eigenschaft auch Flags für Metadatenoptionen angeben. Diese Flags werden nach der Registrierung in den Eigenschaftenmetadaten in diskrete Eigenschaften konvertiert und verwendet, um bestimmte Bedingungen an andere Prozesse zu kommunizieren, z. B. an das Layoutmodul.

Festlegen von geeigneten Metadatenflags

• Wenn sich die Eigenschaft (oder Änderungen ihrer Werte) auf die Benutzeroberfläche (user interface, UI) auswirkt und speziell beeinflusst, wie das Layoutsystem das Element auf einer Seite rendert und diesem eine Größe zuordnet, müssen Sie eine oder mehrere der folgenden Flags festlegen: AffectsMeasure, AffectsArrange, AffectsRender.

  • AffectsMeasure gibt an, dass eine Änderung dieser Eigenschaft eine Änderung der Benutzeroberfläche-Darstellung erfordert, weil das enthaltende Objekt innerhalb des übergeordneten Objekts ggf. mehr oder weniger Platz benötigt. Sie sollten dieses Flag z. B. für eine Eigenschaft festlegen, die für die Breite (width) zuständig ist.

  • AffectsArrange gibt an, dass eine Änderung dieser Eigenschaft eine Änderung der Benutzeroberfläche-Darstellung erfordert, bei der sich normalerweise keine Änderung des zugewiesenen Bereichs ergibt, die jedoch angibt, dass sich die Positionierung innerhalb des Bereichs geändert hat. Sie sollten dieses Flag z. B. für eine Eigenschaft festlegen, die für die Ausrichtung (alignment) zuständig ist.

  • AffectsRender gibt an, dass eine andere Änderung durchgeführt wurde, die sich nicht auf das Layout und die Maße auswirkt, die jedoch ein weiteres Rendering erfordert. Ein Beispiel hierfür ist eine Eigenschaft, die eine Farbe eines vorhandenen Elements ändert, z. B. den Hintergrund (background).

  • Diese Flags werden häufig als Protokoll in Metadaten für Ihre eigenen Überschreibungsimplementierungen von Eigenschaftensystem- oder Layoutrückrufen verwendet. Sie können z. B. einen OnPropertyChanged-Rückruf verwenden, der InvalidateArrange aufruft, wenn eine Eigenschaft der Instanz eine Wertänderung berichtet und AffectsArrange in ihren Metadaten auf true gesetzt ist.

• Einige Eigenschaften können sich auf die Renderingmerkmale des enthaltenden übergeordneten Elements auf eine Art und Weise auswirken, die über die oben erwähnten Änderungen der erforderlichen Größe hinausgeht. Ein Beispiel hierfür ist die MinOrphanLines-Eigenschaft im Flussdokumentmodell, wo Änderungen dieser Eigenschaft das allgemeine Rendering des Flussdokuments ändern können, das den Absatz enthält. Verwenden Sie AffectsParentArrange oder AffectsParentMeasure, um in Ihren Eigenschaften ähnliche Fälle zu identifizieren.

• Standardmäßig unterstützen Abhängigkeitseigenschaften die Datenbindung. Sie können die Datenbindung für Fälle deaktivieren, in denen kein realistisches Szenario für die Datenbindung vorhanden ist oder in denen die Leistung der Datenbindung für ein großes Projekt ein Problem darstellt.

• Standardmäßig hat das Mode-Element der Datenbindung für Abhängigkeitseigenschaften den Wert OneWay. Sie können die Bindung pro Bindungsinstanz immer in TwoWay ändern. Ausführliche Informationen finden Sie unter Gewusst wie: Angeben der Bindungsrichtung. Aber als Entwickler, der die Abhängigkeitseigenschaft erstellt, können Sie festlegen, dass die Eigenschaft standardmäßig den Bindungsmodus TwoWay verwendet. Ein Beispiel für eine vorhandene Abhängigkeitseigenschaft ist MenuItem.IsSubmenuOpen. Bei dieser Eigenschaft interagieren die IsSubmenuOpen-Festlegungslogik und die Zusammenstellung von MenuItem mit dem standardmäßigen Designstil. Die Logik der IsSubmenuOpen-Eigenschaft verwendet die systemeigene Datenbindung, um den Zustand der Eigenschaft im Hinblick auf andere Zustandseigenschaften und Methodenaufrufe beizubehalten. Eine andere Beispieleigenschaft, die standardmäßig die TwoWay-Datenbindung verwendet, ist TextBox.Text.

• Sie können in einer benutzerdefinierten Abhängigkeitseigenschaft auch die Eigenschaftenvererbung aktivieren, indem Sie das Inherits-Flag festlegen. Die Eigenschaftenvererbung ist nützlich, wenn übergeordnete und untergeordnete Elemente eine gemeinsame Eigenschaft aufweisen und wenn es für die untergeordneten Elemente sinnvoll ist, dass der jeweilige Eigenschaftenwert auf den Wert des übergeordneten Elements festgelegt wird. Ein Beispiel für eine vererbbare Eigenschaft ist DataContext. Diese Eigenschaft wird für Bindungsvorgänge verwendet, um das wichtige Master/Detail-Szenario für die Darstellung von Daten zu ermöglichen. Indem Sie DataContext vererbbar machen, erben auch alle untergeordneten Elemente diesen Datenkontext. Aufgrund der Vererbung von Eigenschaftenwerten können Sie im Stammelement der Seite oder Anwendung einen Datenkontext angeben und müssen diese Angabe nicht für Bindungen in allen untergeordneten Elementen wiederholen. DataContext ist ebenfalls ein gutes Beispiel, um zu zeigen, dass die Vererbung den Standardwert überschreibt. Der Wert kann für ein bestimmtes untergeordnetes Element jedoch jederzeit lokal festgelegt werden. Ausführliche Informationen finden Sie unter Gewusst wie: Verwenden des Master/Detail-Musters mit hierarchischen Daten. Die Vererbung von Eigenschaftenwerten kann zu Leistungseinbußen führen und sollte daher sparsam eingesetzt werden. Ausführliche Informationen finden Sie unter Vererbung von Eigenschaftenwerten.

• Legen Sie das Journal-Flag fest, um anzugeben, ob Ihre Abhängigkeitseigenschaft von Journaldiensten der Navigation erkannt und verwendet werden soll. Ein Beispiel hierfür ist die SelectedIndex-Eigenschaft. Jedes Element, das über ein Auswahlsteuerelement ausgewählt wird, sollte beim Navigieren im Journalverlauf beibehalten werden.

Schreibgeschützte Abhängigkeitseigenschaften

Sie können eine Abhängigkeitseigenschaft definieren, die schreibgeschützt ist. Die Szenarios, in denen Sie Ihre Eigenschaft ggf. als schreibgeschützt definieren sollten, weisen jedoch einige Unterschiede auf. Dies ist auch für die Prozedur zum Registrieren der Eigenschaften beim Eigenschaftensystem und zum Offenlegen des Bezeichners der Fall. Weitere Informationen finden Sie unter Schreibgeschützte Abhängigkeitseigenschaften.

Abhängigkeitseigenschaften vom Typ "Auflistung"

Bei Abhängigkeitseigenschaften vom Typ "Auflistung" sind einige zusätzliche Implementierungsaspekte zu beachten. Weitere Informationen finden Sie unter Abhängigkeitseigenschaften vom Auflistungstyp.

Sicherheitsüberlegungen für Abhängigkeitseigenschaften

Abhängigkeitseigenschaften sollten als öffentliche Eigenschaften deklariert werden. Abhängigkeitseigenschaften-Bezeichnerfelder sollten as öffentliche statische Felder deklariert werden. Auch wenn Sie versuchen, andere Zugriffsebenen (z. B. "protected") zu deklarieren, können Sie auf eine Abhängigkeitseigenschaft immer zugreifen, indem Sie den Bezeichner in Verbindung mit den APIs des Eigenschaftensystems verwenden. Es kann ggf. sogar auf ein geschütztes Bezeichnerfeld zugegriffen werden, weil APIs zum Berichten von Metadaten oder zur Wertermittlung Teil des Eigenschaftensystems sind, z. B. LocalValueEnumerator. Weitere Informationen finden Sie unter Sicherheit von Abhängigkeitseigenschaften.

Abhängigkeitseigenschaften und Klassenkonstruktoren

Bei der Programmierung von verwaltetem Code gilt der allgemeine Grundsatz, dass Klassenkonstruktoren keine virtuellen Methoden aufrufen sollten (wird häufig mithilfe von Codeanalysetools erzwungen, z. B. FxCop). Der Grund ist, dass Konstruktoren als Basisinitialisierung eines abgeleiteten Klassenkonstruktors aufgerufen werden können, und das Eingeben der virtuellen Methode über den Konstruktor könnte zu einem Zeitpunkt erfolgen, zu dem das erstellte Objekte einen unvollständigen Initialisierungszustand aufweist. Wenn Sie eine Ableitung von einer Klasse durchführen, die bereits von DependencyObject abgeleitet ist, sollten Sie bedenken, dass das Eigenschaftensystem intern selbst virtuelle Methoden aufruft und offenlegt. Diese virtuellen Methoden sind Teil der Dienste des WPF-Eigenschaftensystems. Das Überschreiben der Methoden ermöglicht es, dass abgeleitete Klassen an der Wertermittlung teilnehmen. Um mögliche Probleme mit der Laufzeitinitialisierung zu vermeiden, sollten Sie in Konstruktoren von Klassen keine Werte von Abhängigkeitseigenschaften festlegen, es sei denn, Sie wenden ein spezielles Konstruktormuster an. Weitere Informationen finden Sie unter Sichere Konstruktormuster für DependencyObjects.

Siehe auch

Konzepte

Übersicht über Abhängigkeitseigenschaften

Metadaten für Abhängigkeitseigenschaften

Übersicht über das Erstellen von Steuerelementen

Abhängigkeitseigenschaften vom Auflistungstyp

Sicherheit von Abhängigkeitseigenschaften

Laden von XAML und Abhängigkeitseigenschaften

Sichere Konstruktormuster für DependencyObjects