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
.NET Desktop feedback
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für