Freigeben über

Richtlinien für das Entwerfen von anpassbaren Steuerelementen

In diesem Dokument werden eine Reihe bewährter Methoden zusammengefasst, die Sie beim Entwerfen eines Steuerelements berücksichtigen sollten, das Sie auf einfache Weise stilfähig und templatierbar gestalten möchten. Wir kamen durch viel Versuch und Irrtum zu diesem Satz bewährter Methoden, während wir an den Themensteuerungsstilen für das integrierte WPF-Steuerelementsatz arbeiteten. Wir haben gelernt, dass erfolgreiche Formatierung sowohl eine Funktion eines gut gestalteten Objektmodells als auch des Stils selbst ist. Die Zielgruppe für dieses Dokument ist der Kontrollautor, nicht der Stilautor.

Terminologie

"Stilisierung und Gestaltungsvorlagen" beziehen sich auf die Suite von Technologien, mit denen ein Steuerelemententwickler die visuellen Aspekte des Steuerelements der Stilvorlage und der Gestaltungsvorlage des Steuerelements überlassen kann. Diese Reihe von Technologien umfasst:

  • Formatvorlagen (einschließlich Eigenschaftensettern, Triggern und Storyboards).

  • Ressourcen

  • Steuerelementvorlagen.

  • Datenvorlagen.

Eine Einführung in das Formatieren und Vorlagen finden Sie unter "Formatieren und Vorlagen".

Bevor Sie beginnen: Grundlegendes zu Ihrem Steuerelement

Bevor Sie sich mit diesen Richtlinien befassen, ist es wichtig, die gängige Verwendung Ihres Steuerelements zu verstehen und zu definieren. Das Styling eröffnet eine oft unkontrollierbare Vielzahl von Möglichkeiten. Steuerelemente, die für die breite Nutzung in vielen Anwendungen von vielen Entwicklern erstellt wurden, stehen vor der Herausforderung, dass die Formatierung genutzt werden kann, um weitreichende Änderungen an der visualen Darstellung des Steuerelements vorzunehmen. Tatsächlich ähnelt das gestaltete Steuerelement möglicherweise nicht einmal den Absichten des Autors des Steuerelements. Da die Flexibilität durch die Formatierung im Wesentlichen grenzenlos ist, können Sie die Idee der allgemeinen Verwendung nutzen, um Ihre Entscheidungen zu treffen.

Um die allgemeine Verwendung Ihres Steuerelements zu verstehen, ist es gut, über das Wertversprechen des Steuerelements nachzudenken. Was bietet Ihr Steuerelement, das kein anderes Steuerelement bieten kann? Die allgemeine Verwendung impliziert keine bestimmte visuelle Darstellung, sondern die Philosophie des Steuerelements und eine angemessene Menge an Erwartungen an die Verwendung. Dieses Verständnis ermöglicht es Ihnen, einige Annahmen über das Kompositionsmodell und die durch den Stil definierten Verhaltensweisen des Steuerelements im üblichen Fall zu treffen. Wenn Sie beispielsweise die gemeinsame Verwendung von ComboBox verstehen, erhalten Sie keinen Einblick darüber, ob eine bestimmte ComboBox abgerundete Ecken hat, aber Sie erhalten einen Einblick in die Tatsache, dass die ComboBox wahrscheinlich ein Pop-up-Fenster benötigt und eine Möglichkeit zum Umschalten, ob es geöffnet ist.

Allgemeine Richtlinien

  • Erzwingen Sie keine Vorlagenverträge. Der Vorlagenvertrag eines Steuerelements kann aus Elementen, Befehlen, Bindungen, Triggern oder sogar Eigenschafteneinstellungen bestehen, die erforderlich oder erwartet werden, damit ein Steuerelement ordnungsgemäß funktioniert.

    • Minimieren Sie Verträge so weit wie möglich.

    • Entwerfen Sie die Erwartung, dass es während der Entwurfszeit (d. h. bei Verwendung eines Entwurfstools) üblich ist, dass sich eine Steuerelementvorlage in einem unvollständigen Zustand befindet. WPF bietet keine Infrastruktur für einen "Kompositionszustand", daher müssen Steuerelemente so erstellt werden, dass ein solcher Zustand möglicherweise gültig sein könnte.

    • Werfen Sie keine Ausnahmen, wenn ein Element eines Vorlagenvertrags nicht eingehalten wird. In dieser Hinsicht sollten Panels keine Ausnahmen auslösen, wenn sie zu viele oder zu wenige Kind-Elemente haben.

  • Berücksichtigen Sie die periphere Funktionalität in den Vorlagen-Hilfselementen. Jedes Steuerelement sollte sich auf seine Kernfunktionalität und sein wahres Wertversprechen konzentrieren und durch die gemeinsame Verwendung des Steuerelements definiert werden. Verwenden Sie dazu Kompositions- und Hilfselemente innerhalb der Vorlage, um periphere Verhaltensweisen und Visualisierungen zu ermöglichen, d. h. diese Verhaltensweisen und Visualisierungen, die nicht zur Kernfunktionalität des Steuerelements beitragen. Hilfselemente sind in drei Kategorien unterteilt:

    • Eigenständige Hilfstypen sind öffentliche und wiederverwendbare Steuerelemente oder Grundtypen, die in einer Vorlage "anonym" verwendet werden, was bedeutet, dass weder das Hilfselement noch das formatierte Steuerelement das andere wissen. Technisch gesehen kann jedes Element ein anonymer Typ sein, aber in diesem Kontext beschreibt der Begriff diese Typen, die spezielle Funktionen kapseln, um gezielte Szenarien zu ermöglichen.

    • Typbasierte Hilfselemente sind neue Typen, die spezielle Funktionen kapseln. Diese Elemente sind in der Regel mit einem schmaleren Funktionsumfang als gängige Steuerelemente oder Grundtypen konzipiert. Im Gegensatz zu eigenständigen Hilfselementen kennen typbasierte Hilfselemente den Kontext, in dem sie verwendet werden, und müssen in der Regel Daten für das Steuerelement freigeben, zu dessen Vorlage sie gehören.

    • Benannte Hilfselemente sind allgemeine Steuerelemente oder Grundtypen, die ein Steuerelement erwartet, innerhalb seiner Vorlage anhand des Namens zu finden. Diese Elemente erhalten einen bekannten Namen innerhalb der Vorlage, sodass ein Steuerelement das Element finden und programmgesteuert mit ihm interagieren kann. Es kann nur ein Element mit einem bestimmten Namen in einer beliebigen Vorlage vorhanden sein.

    Die folgende Tabelle zeigt unterstützende Elemente, die heute von Steuerelementstilen eingesetzt werden (diese Liste ist nicht vollständig):

    Element Typ Verwendet von
    ContentPresenter Typbasiert Button, CheckBox, RadioButton, Frameusw. (alle ContentControl Typen)
    ItemsPresenter Typbasiert ListBox, ComboBox, Menuusw. (alle ItemsControl Typen)
    ToolBarOverflowPanel Benannt ToolBar
    Popup Eigenständig ComboBox, ToolBar, Menu, ToolTip, usw.
    RepeatButton Benannt Slider, ScrollBar, und so weiter
    ScrollBar Benannt ScrollViewer
    ScrollViewer Eigenständig ListBox, ComboBox, Menu, Frame, usw.
    TabPanel Eigenständig TabControl
    TextBox Benannt ComboBox
    TickBar Typbasiert Slider

  • Minimieren Sie erforderliche vom Benutzer angegebene Bindungen oder Eigenschafteneinstellungen für Hilfselemente. Es ist üblich, dass ein Hilfselement bestimmte Bindungen oder Eigenschafteneinstellungen erfordert, um innerhalb der Steuerelementvorlage ordnungsgemäß funktionieren zu können. Das Hilfselement und das vorlagenbasierte Steuerelement sollten diese Einstellungen so weit wie möglich einrichten. Wenn Sie Eigenschaften festlegen oder Bindungen einrichten, sollten Sie darauf achten, vom Benutzer festgelegte Werte nicht außer Kraft zu setzen. Spezifische bewährte Methoden sind wie folgt:

    • Benannte Hilfselemente sollten vom übergeordneten Element identifiziert werden, und dieses sollte alle erforderlichen Einstellungen für das Hilfselement einrichten.

    • Typbasierte Hilfselemente sollten alle erforderlichen Einstellungen direkt für sich selbst einrichten. Dies erfordert möglicherweise, dass das Hilfselement den Informationskontext abfragt, in dem er verwendet wird, einschließlich des TemplatedParent Steuerelementtyps der Vorlage, in der sie verwendet wird. ContentPresenter bindet beispielsweise automatisch die Content Eigenschaft seiner TemplatedParent an seine Content Eigenschaft, wenn es in einem von ContentControl abgeleiteten Typ verwendet wird.

    • Eigenständige Hilfselemente können auf diese Weise nicht optimiert werden, da weder das Hilfselement noch das übergeordnete Element über das andere wissen.

  • Verwenden Sie die Name-Eigenschaft, um Elemente in einer Vorlage zu kennzeichnen. Ein Steuerelement, das ein Element in seiner Formatvorlage finden muss, um programmgesteuert darauf zuzugreifen, sollte dies mithilfe der Name Eigenschaft und des FindName Paradigmas erfolgen. Ein Steuerelement sollte keine Ausnahme auslösen, wenn ein Element nicht gefunden wird, aber automatisch und ordnungsgemäß die Funktionalität deaktivieren, die dieses Element erfordert.

  • Verwenden Sie bewährte Methoden zum Ausdruck des Status und Verhaltens von Steuerelementen in einem Gestaltungsstil. Es folgt eine geordnete Liste der bewährten Methoden zum Ausdrücken von Steuerelementstatusänderungen und -verhalten in einem Stil. Sie sollten das erste Element in der Liste verwenden, das Ihr Szenario aktiviert.

    1. Eigenschaftsbindung. Beispiel: Bindung zwischen ComboBox.IsDropDownOpen und ToggleButton.IsChecked.

    2. Getriggerte Änderungen von Eigenschaften oder deren Animationen. Beispiel: der Hoverzustand eines Button.

    3. Befehl. Beispiel: LineUpCommand / LineDownCommand in ScrollBar.

    4. Eigenständige Hilfselemente. Beispiel: TabPanel in TabControl.

    5. Typbasierte Hilfstypen. Beispiel: ContentPresenter in Button, TickBar in Slider.

    6. Benannte Hilfselemente. Beispiel: TextBox in ComboBox.

    7. Ereignisse, die von benannten Hilfstypen weitergegeben werden. Wenn Sie von einem Formatelement aus auf Blasenereignisse lauschen, müssen Sie festlegen, dass das Element, das das Ereignis generiert, eindeutig identifiziert werden kann. Beispiel: Thumb in ToolBar.

    8. Benutzerdefiniertes OnRender Verhalten. Beispiel: ButtonChrome in Button.

  • Verwenden Sie Stiltrigger (im Gegensatz zu Vorlagentriggern) sparsam. Trigger, die sich auf Eigenschaften für Elemente in der Vorlage auswirken, müssen in der Vorlage deklariert werden. Trigger, die Eigenschaften des Steuerelements beeinflussen (kein TargetName), können im Stil deklariert werden, es sei denn, Sie wissen, dass das Ändern des Vorlagenlayouts auch den Trigger entfernen soll.

  • Seien Sie konsistent mit vorhandenen Stilmustern. Oft gibt es mehrere Möglichkeiten, ein Problem zu lösen. Berücksichtigen Sie bestehende Designmuster und achten Sie darauf, so weit möglich, konsistent zu sein. Dies ist besonders wichtig für Steuerelemente, die von demselben Basistyp abgeleitet sind (zum Beispiel ContentControl, ItemsControl, RangeBase und so weiter).

  • Machen Sie Eigenschaften verfügbar, um allgemeine Anpassungsszenarien ohne Änderung der Vorlage zu ermöglichen. WPF unterstützt keine austauschbaren oder anpassbaren Teile, sodass ein Benutzer eines Steuerelements nur zwei Methoden zur Anpassung hat: das direkte Festlegen von Eigenschaften oder das Festlegen von Eigenschaften mithilfe von Stilen. Aus diesem Grund ist es sinnvoll, eine begrenzte Anzahl von Eigenschaften hervorzuheben, die gezielt für sehr häufige hochpriorisierte Anpassungsszenarien entworfen sind, die andernfalls eine Neuerstellung von Vorlagen erfordern würden. Hier sind bewährte Methoden zum Aktivieren von Anpassungsszenarien:

    • Sehr häufige Anpassungen sollten als Eigenschaften für das Steuerelement verfügbar gemacht und von der Vorlage genutzt werden.

    • Weniger häufige (aber nicht seltene) Anpassungen sollten als angefügte Eigenschaften verfügbar gemacht und von der Vorlage genutzt werden.

    • Es ist akzeptabel, für bekannte, aber seltene Anpassungen das Erstellen neuer Vorlagen zu erfordern.

Themenüberlegungen

  • Designformatvorlagen sollten versuchen, eine konsistente Semantik der Eigenschaften für alle Designs zu haben, ohne eine Garantie zu geben. Im Rahmen der Dokumentation sollte Ihr Steuerelement über ein Dokument verfügen, das die Eigenschaftsemantik des Steuerelements beschreibt, d. h. die Bedeutung einer Eigenschaft für ein Steuerelement. Beispielsweise sollte das ComboBox Steuerelement die Bedeutung der Background Eigenschaft innerhalb ComboBoxdefinieren. Die Standardformatvorlagen für Ihr Steuerelement sollten der in diesem Dokument definierten Semantik für alle Themen folgen. Benutzer, die Kontrolle haben, sollten hingegen beachten, dass sich die Eigenschaftssemantik je nach Thema ändern kann. In bestimmten Fällen können bestimmte Eigenschaften durch die visuellen Einschränkungen, die für ein bestimmtes Design erforderlich sind, nicht dargestellt werden. (Das Klassische Design verfügt beispielsweise nicht über einen einzigen Rahmen, auf den Thickness für viele Steuerelemente angewendet werden kann.)

  • Themenstile brauchen keine konsistente Auslöser-Semantik über alle Designs hinweg. Das Verhalten, das durch Trigger oder Animationen in einem Steuerelement-Stil verfügbar gemacht wird, kann von Thema zu Thema variieren. Steuerelementbenutzer sollten sich bewusst sein, dass ein Steuerelement nicht unbedingt denselben Mechanismus verwendet, um ein bestimmtes Verhalten in allen Designs zu erzielen. Ein Design kann z. B. eine Animation verwenden, um das Hoververhalten auszudrücken, bei dem ein anderes Design einen Trigger verwendet. Dies kann zu Inkonsistenzen bei der Verhaltenserhaltung bei angepassten Steuerelementen führen. (Das Ändern der Hintergrundeigenschaft wirkt sich z. B. nicht auf den Hoverzustand des Steuerelements aus, wenn dieser Zustand mit einem Trigger ausgedrückt wird. Wenn der Hoverzustand jedoch mithilfe einer Animation implementiert wird, kann der Wechsel in den Hintergrund die Animation und damit der Zustandsübergang irreparabel unterbrechen.)

  • Theme-Stile müssen nicht einheitliche "Layout"-Semantik für alle Designs haben. Die Standardformatvorlage muss z. B. nicht garantieren, dass ein Steuerelement in allen Designs dieselbe Größe belegt oder garantiert, dass ein Steuerelement die gleichen Inhaltsränder /Abstände für alle Designs aufweist.

Siehe auch

  • Last updated on