x:Subclass-Anweisung

Ändert das XAML-Markupkompilierungsverhalten, wenn auch x:Class angegeben wird. Anstatt eine partielle, auf x:Class basierende Klasse zu erstellen, wird die bereitgestellte x:Class als Zwischenklasse erstellt, und dann wird von ihrer bereitgestellten abgeleiteten Klasse erwartet, dass sie auf x:Class basiert ist.

Verwendung von XAML-Attributen

<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
   ...
</object>

XAML-Werte

Wert Beschreibung
namespace Optional. Gibt einen CLR-Namespace an, der classname enthält. Bei Angabe von namespace werden namespace und classname durch einen Punkt (.) getrennt.
classname Erforderlich. Gibt den CLR-Namen der partiellen Klasse an, die das geladene XAML und Ihr CodeBehind für dieses XAML verbindet. Siehe Hinweise.
subclassNamespace Optional. Kann unterschiedlich von namespace sein, wenn jeder Namespace den anderen auflösen kann. Gibt einen CLR-Namespace an, der subclassName enthält. Bei Angabe von subclassName werden subclassNamespace und subclassName durch einen Punkt (.) getrennt.
subclassName Erforderlich. Gibt den CLR-Namen der Unterklasse an.

Abhängigkeiten

Die x:Class-Anweisung muss auch für dasselbe Objekt bereitgestellt werden, und dieses Objekt muss das Stammelement der XAML-Produktion sein.

Hinweise

Die Verwendung von x:Subclass ist in erster Linie für Sprachen vorgesehen, die nicht das deklarieren von Teilklassen unterstützen.

Die als x:Subclass genutzte Klasse darf keine geschachtelte Klasse sein und x:Subclass muss auf das Stammobjekt verweisen, wie im Abschnitt „Abhängigkeiten“ erläutert.

Andernfalls ist die konzeptionelle Bedeutung von x:Subclass in einer .NET XAML Services-Implementierung nicht definiert. Dies liegt daran, dass das Verhalten von .NET XAML Services nicht das Programmiermodell spezifiziert, durch das XAML-Markup und unterstützender Code verbunden sind. Implementierungen weiterer Konzepte im Zusammenhang mit x:Class und x:Subclass werden von bestimmten Frameworks ausgeführt, die Programmiermodelle oder Anwendungsmodelle verwenden, um zu definieren, wie XAML-Markup, kompiliertes Markup und CLR-basierter Codebehind verbunden werden. Jedes Framework verfügt möglicherweise über eigene Buildaktionen, die einige der Verhalten oder spezifischen Komponenten ermöglichen, die in der Buildumgebung enthalten sein müssen. Innerhalb eines Frameworks können Buildaktionen auch je nach der spezifischen CLR-Sprache variieren, die für den CodeBehind verwendet wird.

Hinweise zur WPF-Verwendung

x:Subclass kann sich auf einem Seitenstamm oder auf dem Application-Stamm in der Anwendungsdefinition befinden, in der x:Class bereits vorhanden ist. Das Deklarieren von x:Subclass für ein anderes Element als eines Seiten- oder Anwendungsstamms oder es anzugeben wo kein x:Class vorhanden ist, führt zu einem Kompilierungsfehler.

Das Erstellen abgeleiteter Klassen, die ordnungsgemäß für das x:Subclass-Szenario funktionieren, ist ziemlich komplex. Möglicherweise müssen Sie die Zwischendateien untersuchen (die im Obj-Ordner Ihres Projekts erstellten „.g“-Dateien, indem Sie Markup kompilieren, mit Namen, die die XAML-Dateinamen integrieren). Diese Zwischendateien können Ihnen helfen, den Ursprung bestimmter Programmierkonstrukte in den verknüpften Teilklassen in der kompilierten Anwendung zu bestimmen.

Ereignishandler in der abgeleiteten Klasse müssen internal override (Friend Overrides in Microsoft Visual Basic) sein, um die Stubs für die Handler überschreiben zu können, die während der Kompilierung als Zwischenklassen erstellt wurden. Andernfalls wird von den abgeleiteten Klassenimplementierungen ein Shadowing für die Zwischenklassenimplementierung ausgeführt und die Zwischenklassenhandler werden nicht aufgerufen.

Wenn Sie sowohl x:Class als auch x:Subclass definieren müssen Sie keine Implementierung für die Klasse bereitstellen, auf die von x:Class verwiesen wird. Sie müssen ihr nur über das x:Class-Attribut einen Namen geben, sodass der Compiler einige Anleitungen für die zu erstellende Klasse in den Zwischendateien findet (der Compiler wählt in diesem Fall keinen Standardnamen aus). Sie können der x:Class-Klasse eine Implementierung geben. Dies ist jedoch nicht das typische Szenario für die Verwendung von x:Class wie auch x:Subclass.

Weitere Informationen