Erweiterbare Architektur des WPF-Designers

Artikel
08/10/2011

Der WPF Designer für Visual Studio ist eine visuelle Bearbeitungsumgebung für WPF- und Silverlight-Elemente. Der WPF-Designer basiert auf einem Framework mit einer erweiterbaren Architektur zum Erstellen einer eigenen angepassten Entwurfsumgebung.

Durch Erweitern des WPF-Designer-Frameworks können die Darstellung zur Entwurfszeit und das Verhalten von WPF- und Silverlight-Inhalten in einem bemerkenswerten Maß angepasst werden. Sie können den WPF-Designer beispielsweise auf die folgenden Arten erweitern:

Anpassen der Symbole zum Verschieben und Ändern der Größe mit verbesserten Grafiken.
Fügen Sie der Entwurfsoberfläche, die den Zustand eines Steuerelements ändert, ein Kontextmenü hinzu.
Ändern der Entwurfszeitdarstellung und des Verhaltens eines Steuerelements über verschiedene Tools hinweg.

Die WPF-Designer-Architektur unterstützt vollständig die beeindruckende Leistungsfähigkeit von WPF und Silverlight. Dadurch wird erstmalig das Erstellen vieler verschiedener visueller Entwurfsumgebungen möglich.

Ein Beispiel für die Implementierung einer benutzerdefinierten Entwurfszeiterfahrung für WPF und Visual Studio finden Sie unter Exemplarische Vorgehensweise: Erstellen eines Entwurfszeitadorners.

Beispielcode, in dem das Erstellen benutzerdefinierter Entwurfsumgebungen für WPF and Silverlight veranschaulicht wird, finden Sie auf der Website mit den Beispielen für WPF-Designer-Erweiterbarkeit.

WPF-Designer-Framework

Das WPF-Designer-Framework ist modular aufgebaut. Daher müssen Sie beim Erweitern der Entwurfszeit lediglich die Elemente erweitern, die für die vorgesehenen Funktionen erforderlich sind. Sie müssen nicht viel unterstützenden Code schreiben, um die benutzerdefinierten Entwurfsfeatures zu ermöglichen.

Das Objektmodell besteht aus fünf Funktionseinheiten, die in der folgenden Tabelle beschrieben werden.

Funktionseinheit	Beschreibung
Bearbeitungsmodell	Programmierschnittstelle für die Objekte im Designer.
Featureanbieter	Wichtigster Erweiterbarkeitspunkt im Designerframework.
Bearbeitungskontext	Zentraler Speicherort für den Zustand eines Designers.
Befehle, Aufgaben und Tools	Befehle, Aufgaben und Tools zur Verarbeitung von Benutzereingaben.
Entwurfszeitmetadaten	Assemblys, die das Entwurfszeitverhalten eines Steuerelements enthalten, um die Designerlogik physisch von der Laufzeitlogik zu trennen.

Die folgende Abbildung zeigt die funktionalen Einheiten des WPF-Designer-Frameworks.

Übergeordnetes Objektmodell

Bearbeitungsmodell

Die Entwurfsumgebung interagiert mit Laufzeitsteuerelementen über eine Programmierschnittstelle, die als Bearbeitungsmodell bezeichnet wird. Das Bearbeitungsmodell besteht aus drei Funktionsuntereinheiten: einem Modell, einem öffentlichen Wrapper zum Abstrahieren des Modells und einer Ansicht, die die Benutzeroberfläche des Modells darstellt.

Die Entwurfsumgebung verwendet den ModelItem-Typ zur Kommunikation mit dem zugrunde liegenden Modell. Alle Änderungen werden an den ModelItem-Wrappern vorgenommen, die sich auf das zugrunde liegende Modell auswirken. Dadurch kann das Modell einfach gehalten werden. Die ModelItem-Wrapper behandeln komplexe Designerfeatures, beispielsweise Transaktionsunterstützung, Verfolgen von Rückgängigfunktionen und Änderungsbenachrichtigungen.

Die ModelService-Klasse stellt den Einstiegspunkt für das Bearbeitungsmodell und globale Ereignisbenachrichtigungen bereit.

Die ViewService-Klasse ordnet den zugrunde liegenden Modellelementen visuelle Darstellungen zu.

Beide Dienste sind erforderlich, damit der Designer funktioniert. Die DesignerView-Klasse, verantwortlich für das Verarbeiten von Benutzereingaben und das Weiterleiten der Eingaben an entsprechende Befehle, benötigt diese beiden Dienste, um die Benutzereingaben wiederum dem Modell korrekt zuzuordnen.

Featureanbieter

Sie erweitern das Entwurfszeitverhalten von Typen, indem Sie die FeatureProvider-Klasse oder die FeatureConnector<TFeatureProviderType>-Klasse verwenden. Die FeatureConnector<TFeatureProviderType>-Klasse verwaltet eine Liste von FeatureProvider-Objekten.

Die FeatureProvider-Klasse stellt den grundlegendsten Erweiterbarkeitspunkt bereit. Ein Featureanbieter ist ein einfaches Feature oder Add-In, das üblicherweise keine großen Anforderungen an die Entwurfsumgebung stellt und in einem bestimmten Kontext erstellt und zerstört wird. Featureanbieter werden zum Hinzufügen kleiner neuer Benutzeroberflächenelemente zur Entwurfsoberfläche oder zum Anpassen von einfachem Verhalten verwendet. So kann ein Featureanbieter beispielsweise weitere Ziehpunkte oder eine neue Möglichkeit zum Ziehen mit der Maus zur Verfügung stellen.

Leiten Sie von der FeatureConnector<TFeatureProviderType>-Klasse ab, um auf die tiefste Ebene der Erweiterbarkeit zuzugreifen. Diese Klasse macht einen Dienstanbieter verfügbar, über den durch abgeleitete Featureconnectorklassen Ereignisse und Anforderungen verarbeitet sowie Dienste veröffentlicht werden können. Beispielsweise können Sie einen Featureconnector implementieren, um eine Auswahloberfläche oder objektspezifische Serialisierung bereitzustellen.

Im Allgemeinen implementieren Sie ein Feature zum Erweitern vorhandener Konzepte. Implementieren Sie einen Featureconnector, um neue Konzepte bereitzustellen. Weitere Informationen finden Sie unter Featureanbieter und Featureverbindungen.

Bearbeitungskontext

Ein wesentlicher Teil der Zustandsinformationen wird in einem ausgeführten Designer akkumuliert. So kann der Designerzustand beispielsweise beinhalten, welche Objekte ausgewählt sind oder welches Verhalten beim Drücken der linken Maustaste ausgelöst wird. Der Zustand des Designers wird an einem zentralen Speicherort gespeichert, damit er bei Bedarf zur Verfügung steht. Die EditingContext-Klasse stellt dieses zentrale Repository für den Designerzustand dar.

Die EditingContext-Klasse trennt den Zustand in zwei Kategorien: Daten und Verhalten. Daten werden in Form einer Tabelle von Kontextelementen und Verhalten in Form einer Tabelle von Diensten gespeichert. Beide Tabellen werden über einen typbasierten Schlüssel indiziert und sind aufzählbar.

Die ContextItem-Klasse enthält einen einzelnen Bestandteil des Designerzustands. Kontextelemente sind unveränderlich, neue Kontextelemente können jedoch vorhandene Kontextelemente ersetzen und so Veränderlichkeit simulieren.

Auf Dienste kann über die Services-Eigenschaft zugegriffen werden, die eine Instanz von ServiceManager zurückgibt, und auf Kontextelemente kann über die Items-Eigenschaft zugegriffen werden, die eine Instanz von ContextItemManager zurückgibt.

Befehle, Aufgaben und Tools

Die WPF-Designer-Toolarchitektur besteht aus Befehlen, Aufgaben und Tools.

Ein Befehl ist ein eindeutiger Bezeichner, der ein bestimmtes Verhalten darstellt. Beispielsweise ist "Ausschneiden" ein Befehl, der den aktuellen Text ausschneidet und in die Zwischenablage kopiert. Der Code zum Implementieren des Befehls "Ausschneiden" variiert von Anwendung zu Anwendung, ja sogar innerhalb einer Anwendung. So besteht beispielsweise das Ausschneiden von Text in einem Word-Dokument aus einer anderen Implementierung als das Ausschneiden von Text im Textsuchfeld desselben Dokuments. Unabhängig von der Implementierung bleibt der Befehl "Ausschneiden" konstant.

Der WPF-Designer erweitert das WPF-Befehlssystem durch Einführung eines Konzepts von Toolbefehlen. Ein Toolbefehl implementiert die ICommand-Schnittstelle und ähnelt der RoutedCommand-Klasse.

Eine Aufgabe verfügt über eine Auflistung von Befehlsbindungen, die Ihnen das Hinzufügen von weitergeleiteten Befehlen ermöglicht. Die DesignerView-Klasse enthält Code, der die gleiche Weiterleitungsstrategie wie Toolbefehle zum Suchen und Ausführen von in Aufgaben definierten weitergeleiteten Befehlen verwendet. Die DesignerView-Klasse ermöglicht Aufgaben, die allgemeine WPF-Befehle unterstützen, z. B. Copy.

Ein Tool ist eine Klasse, die Benutzereingaben verarbeitet. Alle Benutzereingaben erreichen den Designer als ein oder mehrere Eingabeereignisse. Diese Eingabeereignisse werden an das derzeit aktive Tool übergeben, das sie in Eingabebindungen umwandelt. Wenn eine Eingabebindung zurückgegeben wird, wird der Befehl innerhalb der Bindung ausgeführt.

Ein Tool kann den globalen Modus des Designers darstellen. Wenn ein Benutzer beispielsweise Komponenten auf der Entwurfsoberfläche auswählt, ist dieser Auswahlmodus möglich, da das derzeit aktive Tool Eingabebindungen und Befehle zum Behandeln von Auswahlen bereitstellt. Wenn der Benutzer eine neue Instanz eines Steuerelements erstellt, wird ein anderes Tool mit anderen Befehlen aktiviert, die an dieselben Eingabebindungen gebunden werden.

Entwurfszeitmetadaten

Im WPF-Designer-Framework werden Metadaten zur Definition des Entwurfszeitverhaltens eines Steuerelements mithilfe von Attributen angegeben und in einer separaten Assembly abgelegt. Verschiedene Designer können verschiedene Metadatenassemblys mit vollkommen unterschiedlichen Entwurfszeitimplementierungen verwenden. Dies entkoppelt das Entwurfszeitverhalten vom Laufzeitverhalten, sodass der Designer unabhängig vom Steuerelement überarbeitet werden kann.

Um eine Assembly anzugeben, die die Entwurfszeitimplementierung bereitstellt, markieren Sie die Assembly mit ProvideMetadataAttribute und fügen eine Klasse ein, die die IProvideAttributeTable-Schnittstelle implementiert.

Weitere Informationen finden Sie unter Bereitstellen von Entwurfszeitmetadaten.

Entwurfszeitunterstützung in Expression Blend

Der WPF-Designer unterstützt alle Funktionen im Erweiterbarkeitsframework. Expression Blend unterstützt die folgenden Funktionen.

Adorner
Kontextmenüs
DesignModeValueProvider
Standardinitialisierer
Alle ModelItem-Funktionen, z. B. Auswahl und Bearbeitung
Erweiterbarkeit des Eigenschaftenfensters

Expression Blend bietet keine Unterstützung für ParentAdapter und PlacementAdapter.

WPF-Designerassemblys

Der WPF-Designer besteht aus zahlreichen Assemblys, die zu einer von drei Kategorien gehören: öffentlich, privat oder designerspezifisch.

Die öffentlichen Assemblys machen Klassen verfügbar, die Sie zum Hinzufügen von Entwurfszeitlogik zu Steuerelementen verwenden können.

Die privaten und designerspezifischen Assemblys definieren den Funktionssatz von WPF-Designer und dessen Interaktionen mit Designern wie Visual Studio und Expression Blend.

Die WPF- und Silverlight-Designer werden als einzelne Entität installiert. Es ist kein separates Paket für jeden Designer vorhanden.

Die folgende Tabelle zeigt, wie WPF-Designer-Features bereitgestellt werden.

Assembly	Öffentliche API	Beschreibung
Microsoft.Windows.Design.Extensibility.dll	ja	Stellt mithilfe von Attributen und der Visual Studio SDK-Integrationslogik ein Erweiterbarkeitsmodell bereit.
Microsoft.Windows.Design.Interaction.dll	ja	Stellt Klassen für Benutzereingabe und Anzeige bereit.
Microsoft.Windows.Design.Markup.dll	nein	Stellt XAML- und Dokumentmodellmechanismen bereit.
Microsoft.VisualStudio.Xaml.dll	nein	Stellt über einen Dienst, eine Datenschicht und die Bearbeitung von Metadaten eine grundlegende XAML-Basis für jeden Designer bereit.
Microsoft.Windows.Design.Host.dll	nein	Private API zum Hosten eines Designers (Visual Studio-spezifisch).
Microsoft.Windows.Design.Developer.dll	nein	WPF-Designer-Implementierung
Microsoft.Windows.Design.Developer.WPF.dll	nein
Microsoft.Windows.Design.Developer.Silverlight.dll	nein
Microsoft.Windows.Design.Platform.dll	nein	Plattformebene mit abstrakten Klassen. Plattformimplementierungen implementieren abstrakte Klassen in dieser Assembly.
Microsoft.Windows.Design.Platform.WPF.dll	nein	Plattformspezifische Entwurfszeit für WPF.
Microsoft.Windows.Design.Platform.Silverlight.dll	nein	Plattformspezifische Entwurfszeit für Silverlight.
Microsoft.Expression.DesignModel.dll	nein	Entwurfszeitassembly von Expression Blend.
Microsoft.Expression.Platform.WPF.dll	nein	Entwurfszeitassembly von Expression Blend.
Microsoft.Expression.Platform.Silverlight.dll	nein	Entwurfszeitassembly von Expression Blend.

Tipp

Assemblys stellen Funktionsgrenzen dar, nicht Namespacegrenzen. Sie werden oft Namespaces antreffen, die mehr als eine Assembly umfassen.

Die Architektur von WPF-Designer und Windows Forms-Designer

Die WPF-Designer-Architektur unterscheidet sich wesentlich von der Architektur von Windows Forms-Designer, die sich durch die IComponent-Schnittstelle und den System.ComponentModel-Namespace auszeichnet. Weitere Informationen finden Sie unter Vergleich der Frameworks des Windows Forms-Designers und des WPF-Designers.