x:Subclass Attribute
Modifies XAML compilation behavior in cases where x:Class is also provided. Specifically, instead of creating a partial class based on the page class, the provided x:Class is created as an intermediate class, and then your provided derived class is expected to be based on x:Class.
XAML Attribute Usage
<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
...
</object>
XAML Values
namespace |
Optional. Specifies a CLR namespace that contains classname. If namespace is specified, a dot (.) separates namespace and classname. |
classname |
Required. Specifies the CLR name of the partial class that connects the loaded XAML and your code-behind for that XAML. See Remarks. |
subclassNamespace |
Optional. Can be different than namespace so long as each namespace can resolve the other. Specifies a CLR namespace that contains subclassName. If subclassName is specified, a dot (.) separates subclassNamespace and subclassName. |
subclassName |
Required. Specifies the CLR name of the subclass. |
Dependencies
x:Class Attribute must also be provided on the same element, and that element must be the root element in a page.
Remarks
x:Subclass usage is primarily intended for languages that do not support partial class declarations.
x:Subclass can be declared for any element that is the root of a Extensible Application Markup Language (XAML) page, and/or for the Application root in the application definition, which already has x:Class. Declaring x:Subclass on any element other than a page or application root, or specifying it where no x:Class exists, will result in a compile-time error.
Creating derived classes that work correctly for the x:Subclass scenario is fairly complex. You might need to examine the intermediate files (the .g files produced in the obj folder of your project, with names that incorporate the .xaml file names). These intermediate files can help you determine the origin of certain programming constructs in the joined partial classes within the compiled application.
The class used as the x:Subclass cannot be a nested class.
Event handlers in the derived class must be internal override (Friend Overrides in Microsoft Visual Basic .NET) in order to override the stubs for the handlers as created in the intermediate class during compilation. Otherwise the derived class implementations would hide (shadow) the intermediate class implementation and the intermediate class handlers would fail to be invoked.
When you define both x:Class and x:Subclass , you do not need to provide any implementation for the class referenced by x:Class. You only need to give it a name via the x:Class attribute, such that the compiler has some guidance for the class that it creates in the intermediate files (the compiler does not choose a default name in this case). You can give the x:Class class an implementation if you want, but this is not within the typical scenario for using both x:Class and x:Subclass.