Richtlinien zum Entwerfen formatierbarer Steuerelemente
Aktualisiert: November 2007
In diesem Dokument werden die bewährten Methoden zusammengefasst, die beim Entwickeln eines Steuerelements zu berücksichtigen sind, das Sie auf einfache Weise formatieren und als Vorlage verwenden möchten. Diese bewährten Methoden sind während der Arbeit an den Formatvorlagen für Designsteuerelemente für die integrierte WPF-Steuerelementgruppe durch Versuch und Irrtum zusammengestellt worden. Es hat sich gezeigt, dass eine erfolgreiche Formatierung sowohl eine Funktion eines gut entworfenen Objektmodells als auch des eigentlichen Stils darstellt. Dieses Dokument richtet sich an Autoren von Steuerelementen und nicht an Autoren von Stilen.
Dieses Thema enthält folgende Abschnitte.
- Terminologie
- Vor dem Start: Verstehen des Steuerelements
- Allgemeine Richtlinien
- Designüberlegungen
- Verwandte Abschnitte
Terminologie
"Formatierung und Vorlagen" bezieht sich auf die Suite von Technologien, die es einem Autor von Steuerelementen ermöglichen, die visuellen Aspekte des Steuerelements erst bei Stil und Vorlage des Steuerelements zu berücksichtigen. Diese Suite von Technologien umfasst:
Stile (einschließlich Eigenschaftensetter, Trigger und Storyboards)
Ressourcen
Steuerelementvorlagen
Datenvorlagen
Eine Einführung in Formatierung und Vorlagen finden Sie unter Erstellen von Formaten und Vorlagen.
Vor dem Start: Verstehen des Steuerelements
Bevor Sie sich mit diesen Richtlinien beschäftigen, sollten Sie die typische Verwendung des Steuerelements verstanden und definiert haben. Beim Formatieren stehen häufig zahlreiche Möglichkeiten zur Verfügung. Bei Steuerelementen, die für eine allgemeine Verwendung (in vielen Anwendungen, von vielen Entwicklern) geschrieben werden, kann die visuelle Darstellung des Steuerelements durch Formatierungen grundlegend geändert werden. Möglicherweise hat das formatierte Steuerelement keinerlei Ähnlichkeit mehr mit dem vom Autor geplanten Steuerelement. Da die Flexibilität der Formatierung nahezu grenzenlos ist, können Sie Ihre Entscheidungen auf der Grundlage der typischen Verwendung treffen.
Um die typische Verwendung des Steuerelements zu verstehen, sollten Sie über die Vorteile des Steuerelements nachdenken. Was trägt das Steuerelement zur Tabelle bei, das kein anderes Steuerelement anbieten kann? Die typische Verwendung setzt keine bestimmte visuelle Darstellung voraus. Es geht vielmehr um die Philosophie des Steuerelements und um realistische Erwartungen hinsichtlich der Verwendung. Mithilfe dieser Kenntnisse können Sie Vermutungen über das Kompositionsmodell und das formatdefinierte Verhalten des Steuerelements in der typischen Verwendung anstellen. Bei einem ComboBox gibt Ihnen das Verständnis der typischen Anwendung keinen Aufschluss darüber, ob ein bestimmtes ComboBox abgerundete Ecken aufweist. Es zeigt Ihnen jedoch, dass das ComboBox vermutlich ein Popupfenster und Elemente zum Umschalten benötigt.
Allgemeine Richtlinien
Setzen Sie Vorlagenverträge nicht strikt durch. Der Vorlagenvertrag eines Steuerelements kann aus Elementen, Befehlen, Bindungen, Triggern oder auch Eigenschafteneinstellungen bestehen, die für die ordnungsgemäße Funktionsweise eines Steuerelements erforderlich sind oder erwartet werden.
Minimieren Sie Verträge so weit wie möglich.
Gehen Sie beim Entwurf von der Annahme aus, dass sich eine Steuerelementvorlage zur Entwurfszeit (d. h. beim Verwenden eines Entwurftools) häufig in einem unvollständigen Zustand befindet. WPF bietet keine Zustandsinfrastruktur für die Erstellung. Deshalb muss bei der Erstellung von Steuerelementen davon ausgegangen werden, dass ein solcher Zustand gültig sein kann.
Lösen Sie keine Ausnahmen aus, wenn ein Aspekt eines Vorlagenvertrags nicht beachtet wird. Dementsprechend sollten Bereiche keine Ausnahmen auslösen, wenn sie zu viele oder zu wenige untergeordnete Elemente aufweisen.
Unterteilen Sie die periphere Funktionalität in Vorlagenhilfselemente. Der Schwerpunkt jedes Steuerelements sollte auf der Basisfunktionalität sowie den wirklichen Vorteilen liegen, und die Definition sollte auf der typischen Verwendung des Steuerelements basieren. Verwenden Sie dazu Kompositions- und Hilfselemente in der Vorlage, um Peripherieverhalten und -darstellungen zu aktivieren, d. h., Verhalten und Darstellungen, die nicht zur Basisfunktionalität des Steuerelements beitragen. Hilfselemente lassen sich in drei Kategorien einteilen:
Eigenständige Hilfstypen sind öffentliche und wieder verwendbare Steuerelemente oder Primitiven, die in einer Vorlage "anonym" verwendet werden, sodass weder das Hilfselement noch das formatierte Steuerelement das jeweils andere Element bemerkt. Technisch gesehen kann jedes Element anonym sein, aber in diesem Kontext beschreibt dieser Begriff die Typen, die spezialisierte Funktionalität kapseln, um Zielszenarien zu aktivieren.
Typbasierte Hilfselemente sind neue Typen, die spezialisierte Funktionalität kapseln. Diese Elemente werden in der Regel mit einer geringeren Bandbreite an Funktionalität entworfen als allgemeine Steuerelemente oder Primitive. Im Gegensatz zu eigenständigen Hilfselementen erkennen typbasierte Hilfselemente den Kontext, in dem sie verwendet werden, und müssen in der Regel die Daten mit dem Steuerelement gemeinsam nutzen, zu dessen Vorlage sie gehören.
Benannte Hilfselemente sind allgemeine Steuerelemente oder Primitive, nach denen ein Steuerelement anhand des Namens in der Vorlage sucht. Diese Elemente erhalten einen bekannten Namen in der Vorlage, damit das Steuerelement das Element finden und programmgesteuert mit ihm interagieren kann. In jeder Vorlage kann es nur ein Element mit einem bestimmten Namen geben.
In der folgenden Tabelle werden die Hilfselemente aufgelistet, die derzeit von Steuerelementen verwendet werden (diese Liste ist nicht vollständig):
Element
Typ
Verwendet von
Typbasiert
Button, CheckBox, RadioButton, Frame usw. (alle ContentControl-Typen)
Typbasiert
ListBox, ComboBox, Menu usw. (alle ItemsControl-Typen)
Benannt
Eigenständig
Benannt
Benannt
Eigenständig
Eigenständig
Benannt
Typbasiert
Minimieren Sie erforderliche vom Benutzer angegebene Bindungen oder Eigenschafteneinstellungen für Hilfselemente. Für Hilfselemente sind in der Regel bestimmte Bindungen oder Eigenschafteneinstellungen erforderlich, damit sie in der Steuerelementvorlage ordnungsgemäß funktionieren. Das Hilfselement und das Steuerelement mit Vorlagen sollten diese Einstellungen so weit wie möglich festlegen. Beim Festlegen von Eigenschaften oder Bindungen muss darauf geachtet werden, dass keine vom Benutzer festgelegten Werte überschrieben werden. Bestimmte bewährte Methoden lauten wie folgt:
Benannte Hilfselemente sollten durch das übergeordnete Element identifiziert werden, und das übergeordnete Element sollte alle erforderlichen Einstellungen für das Hilfselement vornehmen.
Typbasierte Hilfselemente sollten alle erforderlichen Einstellungen unmittelbar selbst vornehmen. Dazu muss das Hilfselement möglicherweise Informationskontext abfragen, in dem es verwendet wird, einschließlich TemplatedParent (der Steuerelementtyp der Vorlage, in dem es verwendet wird). ContentPresenter bindet beispielsweise automatisch die Content-Eigenschaft für sein TemplatedParent an seine Content-Eigenschaft, wenn die Verwendung in einem von ContentControl abgeleiteten Typ erfolgt.
Eigenständige Hilfselemente können nicht auf diese Weise optimiert werden, da per Definition weder das Hilfselement noch das übergeordnete Element das jeweils andere Element bemerkt.
Verwenden Sie die Name-Eigenschaft, um Elemente innerhalb einer Vorlage zu kennzeichnen. Ein Steuerelement, das ein Element in seinem Stil finden muss, um programmgesteuert darauf zuzugreifen, sollte dazu die Name-Eigenschaft und das FindName-Paradigma verwenden. Ein Steuerelement sollte keine Ausnahme auslösen, wenn ein Element nicht gefunden wird. Stattdessen sollte die Funktionalität, die dieses Element erfordert, automatisch und ordnungsgemäß deaktiviert werden.
Verwenden Sie die bewährten Methoden, um Zustand und Verhalten des Steuerelements in einem Stil auszudrücken. Es folgt eine sortierte Liste der bewährten Methoden, um Änderungen an Zustand und Verhalten des Steuerelements in einem Stil auszudrücken. Verwenden Sie das erste Element aus der Liste, das das Szenario aktiviert.
Eigenschaftenbindung. Beispiel: Bindung zwischen ComboBox.IsDropDownOpen und ToggleButton.IsChecked.
Ausgelöste Eigenschaftenänderungen oder Eigenschaftenanimationen. Beispiel: Der Hoverzustand einer Button.
Befehl. Beispiel: LineUpCommand/LineDownCommand in ScrollBar.
Eigenständige Hilfselemente. Beispiel: TabPanel in TabControl.
Typbasierte Hilfstypen. Beispiel: ContentPresenter in Button, TickBar in Slider.
Bubbled-Ereignisse aus benannten Hilfstypen. Wenn Sie Bubbled-Ereignisse aus einem Stilelement überwachen, fordern Sie an, dass das Element, das das Ereignis generiert, eindeutig identifiziert werden kann. Beispiel: Thumb in ToolBar.
Benutzerdefiniertes OnRender-Verhalten. Beispiel: ButtonChrome in Button.
Verwenden Sie Stiltrigger (im Gegensatz zu Vorlagentriggern) sparsam. Trigger, die Eigenschaften für Elemente in der Vorlage beeinflussen, müssen in der Vorlage deklariert werden. Trigger, die Eigenschaften für das Steuerelement (kein TargetName) beeinflussen, können im Stil deklariert werden, sofern bekannt ist, dass beim Ändern der Vorlage auch der Trigger zerstört wird.
Bleiben Sie mit vorhandenen Formatierungsmustern konsistent. Oft gibt es mehrere Möglichkeiten, ein Problem zu lösen. Beachten Sie dies, und bleiben Sie nach Möglichkeit mit den vorhandenen Formatierungsmustern für Steuerelemente konsistent. Dies ist besonders bei Steuerelementen wichtig, die von demselben Basistyp abgeleitet werden (beispielsweise ContentControl, ItemsControl, RangeBase usw.).
Machen Sie Eigenschaften verfügbar, um allgemeine Anpassungsszenarien ohne eine erneute Vorlagenerstellung zu aktivieren. WPF unterstützt keine austauschbaren/anpassbaren Teile. Steuerelementbenutzer stehen daher nur zwei Möglichkeiten der Anpassung zur Verfügung: direktes Festlegen der Eigenschaften oder Festlegen der Eigenschaften mithilfe von Stilen. Daher ist es angemessen, eine begrenzte Anzahl Eigenschaften für sehr allgemeine Anpassungsszenarien mit hoher Priorität festzulegen, für die ansonsten eine erneute Vorlagenerstellung erforderlich wäre. Es folgen bewährte Methoden, die angeben, wann und wie Anpassungsszenarien aktiviert werden sollen:
Sehr allgemeine Anpassungen sollten als Eigenschaften für das Steuerelement verfügbar gemacht und von der Vorlage verwendet werden.
Weniger allgemeine (obwohl nicht seltene) Anpassungen sollten als angefügte Eigenschaften verfügbar gemacht und von der Vorlage verwendet werden.
Es ist zulässig, dass für bekannte (aber seltene) Anpassungen eine erneute Vorlagenerstellung erforderlich wird.
Designüberlegungen
Designstile sollten designübergreifend eine konsistente Eigenschaftensemantik aufweisen. Eine Garantie ist jedoch nicht möglich. Die Dokumentation des Steuerelements sollte ein Dokument enthalten, das die Eigenschaftensemantik des Steuerelements beschreibt, d. h. die Bedeutung einer Eigenschaft für ein Steuerelement. Zum Beispiel sollte das ComboBox-Steuerelement die Bedeutung der Background-Eigenschaft für ComboBox definieren. Die Standardstile für das Steuerelement sollten die in diesem Dokument definierte Semantik designübergreifend befolgen. Steuerelementbenutzer sollten sich jedoch der Tatsache bewusst sein, dass die Eigenschaftensemantik je nach Design variieren kann. In manchen Fällen lässt sich eine bestimmte Eigenschaft wegen visueller Einschränkungen, die ein bestimmtes Design erfordert, möglicherweise nicht ausdrücken. (Das Design Classic verfügt z. B. über keinen Einzelrahmen, auf den Thickness für viele Steuerelemente angewendet werden kann.)
Designstile müssen keine designübergreifende konsistente Triggersemantik aufweisen. Das durch Trigger von einem Steuerelementformat verfügbar gemachte Verhalten oder Animationen können je nach Design variieren. Steuerelementbenutzer sollten sich der Tatsache bewusst sein, dass ein Steuerelement nicht in allen Designs denselben Mechanismus einsetzt, um ein bestimmtes Verhalten zu erzielen. In einem Design wird Hoververhalten möglicherweise mit einer Animation ausgedrückt, während in einem anderen Design ein Trigger verwendet wird. Dies kann beim Beibehalten des Verhaltens für angepasste Steuerelemente zu Inkonsistenzen führen. (Das Ändern der Eigenschaft für den Hintergrund wirkt sich möglicherweise nicht auf den Hoverzustand des Steuerelements aus, wenn der Zustand mit einem Trigger ausgedrückt wird. Wenn der Hoverzustand jedoch mit einer Animation implementiert wurde, kann eine Änderung des Hintergrunds die Animation und damit auch den Zustandsübergang irreparabel beschädigen.)
Designstile müssen keine designübergreifende konsistente "Layoutsemantik" aufweisen. Für den Standardstil ist z. B. keine Garantie erforderlich, dass ein Steuerelement in allen Designs dieselbe Größe einnimmt oder in allen Designs dieselben Inhaltsränder/Abstände aufweist.