Vergleich der Frameworks des Windows Forms-Designers und des WPF-Designers
Aktualisiert: November 2007
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. Wenn Sie mit dem Erstellen benutzerdefinierter Implementierungen zur Entwurfszeit für Windows Forms-Steuerelemente vertraut sind, werden Sie feststellen, dass sich die WPF-Designer-Architektur einfacher verwenden und erweitern lässt.
Die WPF-Designer-Architektur übernimmt die TypeConverter-Klasse und TypeDescriptor-Klasse des Windows Forms-Designer-Objektmodells. Die meisten anderen Aspekte der WPF-Designer-Architektur wurden geändert. Weitere Informationen zur Windows Forms-Entwurfszeitarchitektur finden Sie unter Erweitern der Entwurfszeitunterstützung.
Hauptunterschiede zwischen dem ComponentModel-Framework und dem WPF-Framework
Die Unterschiede zwischen der WPF-Designer-Architektur und dem System.ComponentModel-Framework werden in der folgenden Tabelle zusammengefasst.
ComponentModel-Framework |
WPF-Designer-Framework |
|---|---|
Auf Grundlage der Schnittstellen IComponent, IContainer und ISite. |
Auf Grundlage der FrameworkElement-Klasse. |
Stützt sich auf von einem Host bereitgestellte Entwurfszeitdienste. |
Mindestanforderungen werden von Designern deklarativ veröffentlicht. |
Dedizierter Designertyp für jeden Steuerelementtyp. |
Auf einen Steuerelementtyp kann eine beliebige Anzahl von Features ausgeführt werden. |
Metadaten, die für jeden Steuerelementtyp hartcodiert und zur Kompilierungszeit durch das Steuerelement korrigiert werden. |
Metadaten, die in einer separaten Assembly bereitgestellt werden (müssen möglicherweise durch Tools angepasst oder ersetzt werden). Dies ermöglicht eine vom Steuerelement unabhängige Aktualisierung der Entwurfszeitmetadaten. |
Ein IDesignerHost, das den Designerzustand enthält. |
Die EditingContext-Klasse enthält den Designerzustand. |
Dienste werden gesammelt und in einer IServiceContainer-Implementierung freigegeben. |
Die EditingContext-Klasse enthält Dienstverweise. |
Der BehaviorService verwaltet Tastatur, Maus und Befehlsinteraktionen. |
Die WPF-Designer-Toolarchitektur verwaltet Tastatur, Maus und Befehlsinteraktionen. |
Das Bearbeitungsobjektmodell besteht aus den Laufzeitsteuerelementen mit spät gebundenem Zugriff durch die PropertyDescriptor-Klasse. |
Das Bearbeitungsobjektmodell stellt eine Dereferenzierungsschicht zum Abstrahieren der Laufzeitsteuerelemente bereit. Kategorie-Editoren ermöglichen die Bearbeitung mehrerer Eigenschaften in einer Benutzeroberfläche. |
IComponent im Vergleich zu FrameworkElement
WPF-Elemente werden von der FrameworkElement-Klasse abgeleitet, die die Verbindung zwischen den WPF-Basisdiensten und den Elementklassen auf Frameworkebene bereitstellt.
WPF-Elemente implementieren die IComponent-Schnittstelle nicht. Dies ist einer der wesentlichen Gründe dafür, dass der WPF-Designer das System.ComponentModel-Framework nicht verwendet. Dies bedeutet, dass WPF-Steuerelemente niemals positioniert werden. Daher können WPF-Steuerelemente keine Designerdienste aus der System.ComponentModel-Entwurfsumgebung anfordern.
Entwurfszeitdienste
Designer im System.ComponentModel-Framework fordern Dienste aus der Entwurfsumgebung an. Im WPF-Designer-Framework können die meisten Aufgaben durchführt werden, ohne Dienste aus der Umgebung abzufragen.
Im System.ComponentModel-Framework sind innerhalb eines Designerhosts nicht immer Designerdienste vorhanden. Das bedeutet, dass nach jedem Aufruf der GetService-Methode durch benutzerdefinierten Designercode geprüft werden muss, ob ein null-Verweis vorliegt. Designercode muss ordnungsgemäß eingeschränkt werden, wenn ein Dienst nicht vorhanden ist. Diese Einschränkung kann jedoch oft nicht erreicht werden.
Im WPF-Designer-Framework werden die Mindestanforderungen eines benutzerdefinierten Designers deklarativ veröffentlicht. Wenn ein Host den Vertrag nicht erfüllen kann, wird der Designer nicht geladen. Dies macht die Gesamtimplementierung einfacher und stabiler.
Dedizierte Designertypen und das Entkoppeln von Metadaten
Im System.ComponentModel-Framework wird ein Designertyp der entsprechenden Komponente über das DesignerAttribute-Metadatenattribut zugeordnet. Dies bedeutet, dass die Beziehung zur Kompilierungszeit erstellt und eine hartcodierte Abhängigkeit zwischen der Laufzeit der Komponente und deren Entwurfszeitverhalten erzwungen wird. Um einen anderen Designer anzufügen, müssen Sie die DesignerAttribute-Deklaration ändern und die Codebasis der Komponente neu kompilieren.
In WPF-Designer werden die Designermetadaten einer separaten Assembly zugeordnet und somit physisch von der Laufzeitimplementierung entkoppelt. Dadurch können andere Tools vollkommen andere Entwurfsumgebungen für den gleichen Laufzeittyp zur Verfügung stellen. Weitere Informationen finden Sie unter Metadatenspeicher.
Bearbeitungsobjektmodell
Im System.ComponentModel-Framework wird von benutzerdefinierten Designern über die PropertyDescriptor-Klasse spät gebunden auf Steuerelemente zugegriffen. Diese Regel wird von der Entwicklungsumgebung nicht erzwungen. Wenn ein Entwickler vergisst, über die PropertyDescriptor-Klasse auf ein Steuerelement zuzugreifen, treten möglicherweise Fehler auf.
Im WPF-Designer-Framework interagieren benutzerdefinierte Designer über das Bearbeitungsobjektmodell mit Laufzeitsteuerelementen. Dieses Modell stellt eine Dereferenzierungsschicht bereit, die die Steuerelemente in ein Modell und eine Ansicht abstrahiert. Dank dieses Objektmodells muss auf Steuerelemente nicht mehr über die PropertyDescriptor-Klasse zugegriffen werden.
Ähnlichkeit zum ComponentModel-Designerframework
Bearbeitungskontexte sind die Grundlage für den WPF-Designer. Die EditingContext-Klasse enthält den Kontextzustand zu einem Designer.
Das Konzept des Bearbeitungskontexts ist mit dem der IDesignerHost-Schnittstelle im System.ComponentModel.Design-Namespace vergleichbar. Die IDesignerHost-Schnittstelle definiert zahlreiche Features in deren Schnittstelle, jedoch liegt der Schwerpunkt der EditingContext-Klasse auf den Daten- und Verhaltensfeatures.
Der Bearbeitungskontext macht Dienste ähnlich wie die IServiceContainer-Schnittstelle verfügbar. Der Bearbeitungskontext unterstützt Enumeration. Er unterstützt jedoch nicht das Entfernen von Diensten, nachdem diese einmal hinzugefügt wurden. Weitere Informationen finden Sie unter Bearbeiten der Kontextarchitektur.
Unterschiede in der Verwendung von Attributen
Designerattribute haben im WPF-Designer und in Windows Forms-Architekturen unterschiedliche Bedeutungen. In der folgenden Tabelle wird dargestellt, wie sich die designerbezogene Verwendung von Attributen in den beiden Frameworks unterscheidet.
Attribut |
Windows Forms-Eigenschaftenfenster |
WPF-Designer-Eigenschaftenfenster und Expression Blend-Eigenschaftenanalyse |
|---|---|---|
Gibt den an eine Eigenschaft zu übergebenden Wert an, durch den die Eigenschaft ihren Wert von einer anderen Quelle bezieht. Dies wird als Umgebung bezeichnet. |
Nicht zutreffend |
|
Gibt an, ob eine Eigenschaft oder ein Ereignis im Eigenschaftenfenster angezeigt werden soll. |
Gibt an, ob eine Eigenschaft oder ein Ereignis im Eigenschaftenfenster angezeigt werden sollte. Wenn dies für eine normalerweise nicht angezeigte Eigenschaft explizit auf true festgelegt wird, wird diese Eigenschaft angezeigt. |
|
Gibt den Namen der Kategorie an, in der die Eigenschaft oder das Ereignis bei der Anzeige in einem PropertyGrid-Steuerelement gruppiert werden soll, das auf den Modus Nach Kategorien festgelegt ist. |
Gibt den Namen der Kategorie an, in der die Eigenschaft oder das Ereignis gruppiert werden soll, wenn diese in einem Eigenschaftenfenster angezeigt werden. |
|
Gibt den Standardwert für eine Eigenschaft an. |
Gibt für CLR-Datentypen den Standardwert für eine Eigenschaft an. Wird von Abhängigkeitseigenschaften ignoriert. |
|
Gibt eine Beschreibung für eine Eigenschaft oder ein Ereignis an. |
Nicht zutreffend |
|
Gibt den Anzeigenamen für eine Eigenschaft, ein Ereignis oder eine public void-Methode an, die keine Argumente übernimmt. |
Gibt den Namen an, der im Eigenschaftenfenster für die Eigenschaft angezeigt wird, der dieses Attribut zugeordnet ist. |
|
Gibt den Editor an, mit dem eine Eigenschaft geändert werden soll. |
Gibt den Editor an, mit dem eine Eigenschaften ggf. geändert wird (einschließlich der Kategorie-Editoren zum Bearbeiten mehrerer Eigenschaften). |
|
Nicht zutreffend |
EditorBrowsableState.Advanced fügt der Erweiterungsmarke einen Kategorie-Editor oder eine Eigenschaft hinzu. |
|
Gibt das Kontextschlüsselwort für eine Klasse oder einen Member an. |
Nicht zutreffend |
|
Gibt an, ob eine Eigenschaft lokalisiert werden sollte. |
Nicht zutreffend |
|
Gibt an, dass die Textdarstellung eines Objekts von Zeichen, wie z. B. Sternchen, verdeckt wird. |
Nicht zutreffend |
|
Gibt an, ob die Eigenschaft, an die dieses Attribut gebunden ist, zur Entwurfszeit schreibgeschützt ist. |
Gibt an, ob die Eigenschaft, an die dieses Attribut gebunden ist, zur Entwurfszeit schreibgeschützt ist. Mit ReadOnlyAttribute markierte Eigenschaften zeigen in der Eigenschaftenanalyse den Editor für die Objekttextdarstellung schreibgeschützt an. |
|
Gibt an, dass das Eigenschaftenfenster aktualisiert wird, wenn sich der zugehörige Eigenschaftenwert ändert. |
Nicht zutreffend |
|
Gibt an, welcher Typ als Konverter für das Objekt verwendet werden sollte, an das dieses Attribut gebunden ist. |
Gibt an, welcher Typ als Konverter für das Objekt verwendet werden sollte, an das dieses Attribut gebunden ist. |
|
Gibt das Standardereignis für eine Komponente an. |
Gibt das Standardereignis für eine Komponente zum Festlegen an, welcher Ereignishandler per Doppelklick erstellt wird. |
|
Gibt die Standardeigenschaft für eine Komponente an. |
Gibt die Standardeigenschaft für eine Komponente an, in der die standardmäßig ausgewählte Eigenschaft festgelegt wird. |
|
Gibt die Klasse an, die verwendet wird, um Entwurfszeitdienste für eine Komponente zu implementieren. |
Nicht zutreffend |
|
Gibt an, dass der Designer für eine Klasse zu einer bestimmten Kategorie gehört. |
Nicht zutreffend |
|
Stellt ein Attribut eines Toolboxelements dar. |
Nicht zutreffend |
|
Gibt die Filterzeichenfolge und den Filtertyp für eine Toolbox an. |
Nicht zutreffend |
|
Nicht zutreffend |
Verhindert, dass ein Typ in der Toolbox angezeigt wird, wenn eine Assembly auf Typen untersucht wird, um diese zur Toolbox hinzuzufügen. |
|
Nicht zutreffend |
Gibt an, welche Elemente einem Kombinationsfeld für den Auflistungs-Editor oder den Untereigenschaften-Editor hinzugefügt werden. Ermöglicht das Angeben einer Factory zum Anpassen der Erstellung. |
|
Nicht zutreffend |
Gibt die Reihenfolge an, in der die Eigenschaften im Eigenschaftenfenster angezeigt werden. |
Die folgenden Attribute werden im WPF-Designer-Framework verwendet, jedoch nicht im Windows Forms-Designerframework.
Unterschiede beim Angeben von Toolboxsymbolen
Im Windows Forms-Designerframework wird ein Toolboxsymbol für ein benutzerdefinierte Steuerelement angegeben, indem der Steuerelementklasse ein ToolboxBitmapAttribute hinzugefügt wird.
Im WPF-Designer-Framework werden Toolboxbitmaps mithilfe von eingebetteten Ressourcen und Benennungskonventionen angegeben. Zusätzlich kann mit dem ToolboxBrowsableAttribute eingeschränkt werden, welche Typen in einer Assembly für eine Toolbox verfügbar gemacht werden.
Unterschiede beim Angeben von Metadaten
In Windows Forms werden Designermetadaten mithilfe von Attributen (z. B. DesignerAttribute) deklarativ angegeben.
In der WPF-Designer-Architektur werden Designermetadaten in einem Metadatenspeicher angegeben. Weitere Informationen finden Sie unter Metadatenspeicher.