x:Subklassendirektive
Ändert das XAML-Markupkompilierungsverhalten, wenn auch x:Class
bereitgestellt wird. Anstatt eine partielle Klasse zu erstellen, die auf x:Class
basiert, wird das bereitgestellte x:Class
als Zwischenklasse erstellt, und dann wird erwartet, dass die bereitgestellte abgeleitete Klasse auf x:Class
basiert.
XAML-Attributverwendung
<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
...
</object>
XAML-Werte
Wert | Beschreibung |
---|---|
namespace |
Wahlfrei. Gibt einen CLR-Namespace an, der classname enthält. Wenn namespace angegeben ist, trennt ein Punkt (.) namespace und classname . |
classname |
Erforderlich. Gibt den CLR-Namen der partiellen Klasse an, die den geladenen XAML-Code und den CodeBehind für diesen XAML-Code verbindet. Siehe Anmerkungen. |
subclassNamespace |
Wahlfrei. Kann sich von namespace unterscheiden, wenn jeder Namespace die andere auflösen kann. Gibt einen CLR-Namespace an, der subclassName enthält. Wenn subclassName angegeben ist, trennt ein Punkt (.) subclassNamespace und subclassName . |
subclassName |
Erforderlich. Gibt den CLR-Namen der Unterklasse an. |
Abhängigkeiten
x:Class Directive muss auch für dasselbe Objekt bereitgestellt werden, und dieses Objekt muss das Stammelement der XAML-Produktion sein.
Bemerkungen
x:Subclass
Verwendung ist in erster Linie für Sprachen vorgesehen, die partielle Klassendeklarationen nicht unterstützen.
Die klasse, die als x:Subclass
verwendet wird, kann keine geschachtelte Klasse sein, und x:Subclass
müssen auf das Stammobjekt verweisen, wie im Abschnitt "Abhängigkeiten" erläutert.
Andernfalls ist die konzeptionelle Bedeutung von x:Subclass
durch eine .NET XAML Services-Implementierung nicht definiert. Dies liegt daran, dass das Verhalten von .NET XAML Services nicht das gesamte Programmiermodell angibt, mit dem XAML-Markup und Sicherungscode verbunden sind. Implementierungen weiterer Konzepte im Zusammenhang mit x:Class
und x:Subclass
werden von bestimmten Frameworks durchgeführt, die Programmiermodelle oder Anwendungsmodelle verwenden, um zu definieren, wie XAML-Markup, kompiliertes Markup und CLR-basiertes CodeBehind verbunden werden. Jedes Framework verfügt möglicherweise über eigene Buildaktionen, die ein bestimmtes Verhalten ermöglichen, oder bestimmte Komponenten, 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.
WPF-Verwendungshinweise
x:Subclass
kann sich auf einem Seitenstamm oder im Application Stamm in der Anwendungsdefinition befinden, die bereits x:Class
hat. Wenn sie x:Subclass
auf einem anderen Element als einer Seite oder einem Anwendungsstamm deklarieren oder angeben, wo kein x:Class
vorhanden ist, tritt ein Kompilierungsfehler auf.
Das Erstellen abgeleiteter Klassen, die für das szenario x:Subclass
ordnungsgemäß funktionieren, ist ziemlich komplex. Möglicherweise müssen Sie die Zwischendateien (die im Obj-Ordner des Projekts erstellten G-Dateien durch Markupkompilierung mit Namen untersuchen, die die XAML-Dateinamen enthalten). Diese Zwischendateien können Ihnen dabei helfen, den Ursprung bestimmter Programmierkonstrukte in den verknüpften Teilklassen in der kompilierten Anwendung zu ermitteln.
Ereignishandler in der abgeleiteten Klasse müssen internal override
(Friend Overrides
in Microsoft Visual Basic) sein, um die Stubs für die Handler außer Kraft zu setzen, wie in der Zwischenklasse während der Kompilierung erstellt. Andernfalls blenden die abgeleiteten Klassenimplementierungen die Zwischenklassenimplementierung und die Zwischenklassenhandler nicht auf.
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 ihm nur einen Namen über das attribut x:Class
zuweisen, damit der Compiler einige Anleitungen für die Klasse hat, die er in den Zwischendateien erstellt (in diesem Fall wählt der Compiler 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
und x:Subclass
.
Siehe auch
.NET Desktop feedback