Freigeben über


Eigenschaftenänderungsereignisse

Windows Presentation Foundation (WPF) definiert mehrere Ereignisse, die als Antwort auf eine Änderung des Werts einer Eigenschaft ausgelöst werden. Häufig ist die Eigenschaft eine Abhängigkeitseigenschaft. Das Ereignis selbst ist manchmal ein Routingereignis und manchmal ein CLR-Standardereignis (Common Language Runtime). Die Definition des Ereignisses variiert je nach Szenario, da einige Eigenschaftenänderungen besser durch eine Elementstruktur weitergeleitet werden, während andere Eigenschaftenänderungen in der Regel nur für das Objekt von Bedeutung sind, bei dem sich die Eigenschaft geändert hat.

Identifizierung eines Eigenschaftenänderungsereignisses

Nicht alle Ereignisse, die eine Eigenschaftenänderung melden, werden explizit als Eigenschaftenänderungsereignis identifiziert. Dies geschieht entweder durch ein Signaturmuster oder ein Namensmuster. Im Allgemeinen weist die Beschreibung des Ereignisses in der SDK-Dokumentation darauf hin, ob das Ereignis unmittelbar mit einer Eigenschaftswertänderung verbunden ist und Querverweise zwischen der Eigenschaft und dem Ereignis enthält.

Routingeigenschaftenänderungs-Ereignisse

Bestimmte Ereignisse verwenden einen Ereignisdatentyp und Delegaten, die explizit für Eigenschaftenänderungsereignisse verwendet werden. Der Ereignisdatentyp ist RoutedPropertyChangedEventArgs<T>, und der Delegat ist RoutedPropertyChangedEventHandler<T>. Die Ereignisdaten und Delegaten haben einen generischen Typparameter, der verwendet wird, um den tatsächlichen Typ der zu ändernden Eigenschaft anzugeben, wenn Sie den Handler festlegen. Die Ereignisdaten enthalten zwei Eigenschaften (OldValue und NewValue), die dann beide als Typargument in den Ereignisdaten übergeben werden.

Der „weitergeleitete“ Teil des Namens gibt an, dass das Eigenschaftenänderungsereignis als Routingereignis registriert ist. Der Vorteil des Routings eines Eigenschaftenänderungsereignisses liegt darin, dass die oberste Ebene eines Steuerelements Eigenschaftenänderungsereignisse empfangen kann, wenn Eigenschaften von untergeordneten Elementen (zusammengesetzte Komponenten des Steuerelements) die Werte ändern. Sie können beispielsweise ein Steuerelement erstellen, das ein RangeBase-Steuerelement wie z. B. ein Slider-Element enthält. Wenn der Wert der Value-Eigenschaft für den Schieberegler geändert wird, soll die Änderung im übergeordneten Steuerelement und nicht im Part verarbeitet werden.

Da Sie über einen vorherigen und einen neuen Wert verfügen, kann es dazu verleiten, diesen Ereignishandler als ein Validierungssteuerelement für den Eigenschaftswert zu verwenden. Allerdings ist dies nicht der Zweck der meisten Eigenschaften, die durch Ereignisse geändert wurden. Im Allgemeinen werden die Werte bereitgestellt, damit Sie diese Werte in anderen Logikbereichen Ihres Codes ausführen können, aber eigentlich ist das Ändern der Werte aus dem Ereignishandler heraus nicht empfehlenswert und kann zu unbeabsichtigter Rekursion führen, dies ist davon abhängig, wie der Handler implementiert ist.

Wenn Ihre Eigenschaft eine benutzerdefinierte Abhängigkeitseigenschaft ist, oder wenn Sie eine abgeleitete Klasse verwenden, in der Sie den Instanziierungscode festgelegt haben, ist ein viel besserer Mechanismus zum Nachverfolgen von Eigenschaftenänderungen vorhanden, der in das WPF-Eigenschaftensystem integrierten ist: Die Eigenschaftensystemrückrufe CoerceValueCallback und PropertyChangedCallback. Weitere Informationen über die Verwendung des WPF-Eigenschaftensystems für die Überprüfung und Koersion, finden Sie unter Rückrufe und Validierung von Abhängigkeitseigenschaften und Benutzerdefinierten Abhängigkeitseigenschaften.

Abhängigkeitseigenschaftsänderungs-Ereignisse

Ein weiteres Paar von Typen, die Teil eines Szenarios mit Eigenschaftenänderungen sind, sind DependencyPropertyChangedEventArgs und DependencyPropertyChangedEventHandler. Ereignisse für diese Eigenschaftenänderungen werden nicht weitergeleitet; Sie sind CLR-Standardereignisse. DependencyPropertyChangedEventArgs ist ein ungewöhnlicher Ereignisdaten-Berichtstyp, da er nicht von EventArgs abgeleitet ist. DependencyPropertyChangedEventArgs ist eine Struktur, keine Klasse.

Ereignisse, die DependencyPropertyChangedEventArgs und DependencyPropertyChangedEventHandler verwenden, sind etwas gebräuchlicher als RoutedPropertyChanged Ereignisse. Ein Beispiel für ein Ereignis, das diese Typen verwendet, ist IsMouseCapturedChanged.

Wie RoutedPropertyChangedEventArgs<T> meldet auch DependencyPropertyChangedEventArgs einen alten und einen neuen Wert für die Eigenschaft. Außerdem gelten die gleichen Überlegungen dazu, was Sie mit den Werten tun können; im Allgemeinen ist es nicht empfehlenswert, dass Sie versuchen, die Werte für den Absender als Antwort auf das Ereignis erneut zu ändern.

Eigenschaftsauslöser

Ein eng mit einem Eigenschaftenänderungsereignis verbundenes Konzept ist ein Eigenschaftsauslöser. Ein Eigenschaftsauslöser wird innerhalb eines Stils oder einer Vorlage erstellt und ermöglicht es Ihnen, ein bedingtes Verhalten basierend auf dem Wert der Eigenschaft zu erstellen, in dem der Eigenschaftsauslöser zugeordnet ist.

Die Eigenschaft für einen Eigenschaftsauslöser muss eine Abhängigkeitseigenschaft sein. Es kann (und ist häufig) eine schreibgeschützte Abhängigkeitseigenschaft sein. Ein guter Indikator für den Fall, dass eine Abhängigkeitseigenschaft von einem Steuerelement verfügbar gemacht wird, ist zumindest teilweise konzipiert, um ein Eigenschaftsauslöser zu sein, wenn der Eigenschaftsname mit „Is“ beginnt. Eigenschaften, die diese Namen tragen, sind häufig schreibgeschützte boolesche Abhängigkeitseigenschaften, in denen das primäre Szenario für die Eigenschaft den Steuerelementzustand meldet, der möglicherweise Konsequenzen für die Benutzeroberfläche in Echtzeit hat und sich somit als Eigenschaftsauslöserkandidat eignet.

Einige dieser Eigenschaften können auch ein dediziertes Eigenschaftenänderungsereignis haben. Zum Beispiel hat die Eigenschaft IsMouseCaptured ein Eigenschaftenänderungsereignis IsMouseCapturedChanged. Die Eigenschaft selbst ist schreibgeschützt, wobei ihr Wert durch das Eingabesystem angepasst ist, und das Eingabesystem löst IsMouseCapturedChanged bei jeder Änderung in Echtzeit aus.

Im Vergleich zu einem echten Eigenschaftenänderungsereignis, das einen Eigenschaftsauslöser verwendet, um eine Eigenschaftenänderung zu bearbeiten, gelten hier einige Einschränkungen.

Eigenschaftsauslöser funktionieren durch eine genaue Übereinstimmungslogik. Sie legen eine Eigenschaft und einen Wert fest, die den spezifischen Wert angeben für den der Auslöser agiert. Beispiel: <Setter Property="IsMouseCaptured" Value="true"> ... </Setter>. Aufgrund dieser Einschränkung werden die meisten Eigenschaftsauslöser für boolesche Eigenschaften verwendet oder für Eigenschaften, die einen dedizierten Enumerationswert haben, wobei der mögliche Wertebereich überschaubar genug ist, um einen Auslöser für jeden Fall festzulegen. Eigenschaftsauslöser können nur für spezielle Werte vorhanden sein, z.B. wenn die Elementanzahl 0 erreicht, und keine Auslöser vorhanden sind, die Rechenschaft für die Fälle ablegen, wenn der Eigenschaftswert sich erneut von 0 entfernt (an Stelle von Auslösern benötigen Sie hier für alle Fälle ggf. einen Code-Ereignishandler oder ein Standardverhalten, das vom Auslöserstatus erneut zurückschaltet, wenn der Wert ungleich 0 ist).

Die Syntax der Eigenschaftsauslöser entspricht einer „if“-Anweisung in der Programmierung. Wenn die Auslöserbedingung echt ist, wird der „Textkörper“ des Eigenschaftsauslösers „ausgeführt“. Der „Textkörper“ von einem Eigenschaftsauslöser ist kein Code, sondern ein Markup. Dieses Markup ist darin beschränkt ein oder mehrere Setter-Elemente zu verwenden, um andere Eigenschaften des Objekts festzulegen, auf das der Stil oder die Vorlage angewendet wird.

Normalerweise ist es empfehlenswert, den selben Eigenschaftswert auf den Standardwert mithilfe eines Setter festzulegen, um die „if“-Bedingung eines Eigenschaftsauslösers zu versetzen, der über eine Vielzahl von möglichen Werten verfügt. Auf diese Weise besitzt der im Trigger enthaltene Setter Vorrang, wenn die Triggerbedingung auf wahr festgelegt ist und der Setter, der nicht in einem Trigger enthalten ist, besitzt Vorrang, wenn die Triggerbedingung falsch ist.

Eigenschaftsauslöser eigenen sich im Allgemeinen für Szenarios, in denen eine oder mehrere Darstellungseigenschaften sich basierend auf dem Zustand einer anderen Eigenschaft auf dem selben Element ändern sollten.

Weitere Informationen zu Eigenschaftsauslösern finden Sie unter Erstellen von Formaten und Vorlagen.

Siehe auch