Freigeben über

Richtlinien für das Entwerfen von anpassbaren Steuerelementen

  • Artikel

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 bei der Arbeit an den Designvorlagenstilen für das integrierte WPF-Steuerelement-Set zu diesem Satz bewährter Methoden. Wir haben gelernt, dass erfolgreiche Gestaltung ebenso sehr eine Funktion eines gut gestalteten Objektmodells ist wie des Stils selbst. Die Zielgruppe für dieses Dokument ist der Verfasser des Steuerungselements, nicht der Autor der Formatvorlage.

Terminologie

"Stilisierung und Vorlagenerstellung" beziehen sich auf die Technologie-Suite, mit denen ein Steuerelementautor die visuellen Aspekte des Steuerelements auf den Stil und die Vorlage des Steuerelements zurückstellen kann. Diese Reihe von Technologien umfasst:

  • Formatvorlagen (einschließlich Eigenschaften-Setter, Triggern und Storyboards).

  • Ressourcen.

  • Steuerelementvorlagen.

  • Datenvorlagen.

Eine Einführung in das Styling und Templating finden Sie unter Styling und Templating.

Bevor Sie beginnen: Verständnis Ihrer Steuerung

Bevor Sie mit diesen Richtlinien beginnen, ist es wichtig, den üblichen Verwendungszweck Ihres Steuerelements verstanden und definiert zu haben. Die Stilgebung bietet oft eine unkontrollierbare Reihe von Möglichkeiten. Steuerelemente, die für die allgemeine Nutzung (in vielen Anwendungen, von vielen Entwicklern) entwickelt wurden, stehen vor der Herausforderung, dass das Styling genutzt werden kann, um weitreichende Änderungen an der visuellen Darstellung des Steuerelements vorzunehmen. Tatsächlich ähnelt das gestaltete Steuerelement möglicherweise nicht einmal den Vorstellungen des Steuerelementautoren. Da die Flexibilität durch die Formatierung im Wesentlichen grenzenlos ist, können Sie die Idee der üblichen Nutzung verwenden, um Ihre Entscheidungen einzugrenzen.

Um die allgemeine Verwendung Ihres Steuerelements zu verstehen, ist es gut, über das Wertversprechen des Steuerelements nachzudenken. Was bringt Ihr Steuerelement in die Tabelle, die 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. Mit diesem Verständnis können Sie einige Annahmen über das Kompositionsmodell und die durch den Stil definierten Verhaltensweisen des Steuerelements in den meisten Fällen treffen. Im Falle von ComboBox, gibt Ihnen zum Beispiel das Verständnis der allgemeinen Verwendung keinen Einblick darüber, ob ein bestimmter ComboBox abgerundete Ecken hat. Es gibt Ihnen jedoch Einblicke, dass ComboBox wahrscheinlich ein Pop-up-Fenster und eine Möglichkeit zum Öffnen und Schließen benötigt.

Allgemeine Richtlinien

  • Erzwingen Sie Vorlagenverträge nicht strikt. 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.

    • Berücksichtigen Sie bei der Gestaltung die Erwartung, dass es während der Entwurfszeit (also bei der Nutzung eines Entwurfstools) üblich ist, dass sich eine Steuerelementvorlage in einem unvollständigen Zustand befindet. WPF bietet keine Infrastruktur für einen "Zusammenstellung"-Zustand, daher müssen Steuerelemente in der Erwartung entwickelt werden, dass ein solcher Zustand gültig sein könnte.

    • Werfen Sie keine Ausnahmen, wenn ein Element eines Vorlagenvertrags nicht befolgt wird. In diesem Sinne sollten Panels keine Ausnahmen auslösen, wenn sie zu viele oder zu wenige Kinder haben.

  • Beziehen Sie periphere Funktionalität in die Vorlagenhilfelemente ein. 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 dem anderen bekannt sind. 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 spezialisierte Funktionalität 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 der 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 Hilfselemente, die in aktuellen Steuerelement-Styles verwendet werden: (Diese Liste ist nicht vollständig.)

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

  • Minimieren der erforderlichen vom Benutzer angegebenen 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 festlegen. 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:

    • Namentlich genannte Hilfselemente sollten durch das übergeordnete Element identifiziert werden, und das übergeordnete Element sollte alle erforderlichen Einstellungen am Hilfselement vornehmen.

    • Typbasierte Hilfselemente sollten alle erforderlichen Einstellungen direkt für sich selbst einrichten. Dies kann es erforderlich machen, dass das Hilfselement den Informationskontext abfragt, in dem es verwendet wird, einschließlich seines TemplatedParent (der Steuerelementtyp der Vorlage, in der es verwendet wird). Beispielsweise bindet ContentPresenter die Content-Eigenschaft seiner TemplatedParent automatisch an die Content-Eigenschaft, wenn sie in einem ContentControl-abgeleiteten Typ verwendet wird.

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

  • Verwenden Sie die Name-Eigenschaft, um Elemente in einer Vorlagezu 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, sondern die Funktionalität, die dieses Element erfordert, still und elegant deaktivieren.

  • Verwenden Sie bewährte Methoden zum Ausdrücken von Steuerelementstatus und Verhalten in einem Stil. Es folgt eine geordnete Liste bewährter Praktiken zum Ausdruck von Statusänderungen und Verhalten von Steuerelementen 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. Ausgelöste Änderungen oder Animationen von Eigenschaften. 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. Weitergeleitete Ereignisse von benannten Hilfstypen. 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 Verhalten von OnRender. Beispiel: ButtonChrome in Button.

  • Verwenden Sie Formatvorlagentrigger 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 sich auf Eigenschaften des Steuerelements auswirken, können im Stil deklariert werden (keine TargetName), es sei denn, Sie wissen, dass durch das Ändern der Vorlage auch der Trigger zerstört werden soll.

  • Seien Sie konsistent mit vorhandenen Stilmustern. Oft gibt es mehrere Möglichkeiten, ein Problem zu lösen. Beachten Sie bestehende Steuerelement-Styling-Muster und seien Sie nach Möglichkeit mit ihnen konsistent. Dies ist besonders wichtig für Steuerelemente, die von demselben Basistyp abgeleitet sind (z. B. ContentControl, ItemsControl, RangeBaseusw.).

  • Eigenschaften verfügbar machen, um allgemeine Anpassungsszenarien zu ermöglichen, ohneneu zu aktualisieren. WPF unterstützt keine austauschbaren oder anpassbaren Teile, sodass einem Benutzer des Steuerelements nur zwei Anpassungsmethoden zur Verfügung stehen: entweder die Eigenschaften direkt festlegen oder die Eigenschaften mithilfe von Stilen festlegen. Aus diesem Grund ist es sinnvoll, eine begrenzte Anzahl von Eigenschaften für sehr häufige Anpassungsszenarien mit hoher Priorität zu erstellen, die ansonsten eine Umgestaltung 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 gängige (aber nicht seltene) Anpassungen sollten als angefügte Eigenschaften verfügbar gemacht und von der Vorlage genutzt werden.

    • Es ist akzeptabel, dass bekannte, aber seltene Anpassungen eine erneute Erstellung von Vorlagen erfordern.

Themenüberlegungen

  • Themenstile sollten versuchen, eine konsistente Eigenschaftssemantik über alle Designs hinweg zu erzielen, garantieren dies jedoch nicht. 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 Steuerelement ComboBox die Bedeutung der Eigenschaft Background innerhalb von ComboBoxdefinieren. Die Standardstile für Ihr Steuerelement sollten versuchen, der Semantik zu folgen, die in diesem Dokument definiert ist, und dies in allen Designs einzuhalten. Benutzer, die Dinge steuern, sollten hingegen beachten, dass sich die Eigenschaftensemantik von Design zu Design ändern können. In bestimmten Fällen ist eine gegebene Eigenschaft unter den visuellen Einschränkungen, die für ein bestimmtes Thema erforderlich sind, nicht darstellbar. Das klassische Design verfügt beispielsweise nicht über einen einzigen Rahmen, auf den Thickness für viele Bedienelemente angewendet werden kann.

  • Themenstile müssen keine konsistente Triggersemantik in allen Themenhaben. Das Verhalten eines Steuerelementstils, das durch Trigger oder Animationen freigesetzt wird, kann von Thema zu Thema variieren. Benutzer von Steuerelementen sollten sich bewusst sein, dass ein Steuerelement nicht unbedingt denselben Mechanismus einsetzt, um ein bestimmtes Verhalten in allen Themes zu erzielen. Ein Design kann z. B. eine Animation verwenden, um das Hoververhalten auszudrücken, während ein anderes Design einen Auslöser 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.)

  • Themenstile müssen keine konsistente "Layout"-Semantik über alle Designshinweg aufweisen. Die Standardformatvorlage muss z. B. nicht garantieren, dass ein Steuerelement in allen Designs dieselbe Größe hat oder garantieren, dass ein Steuerelement in allen Designs die gleichen Inhaltsränder und Abstände aufweist.

Siehe auch