Директива x:Subclass
Изменяет поведение компиляции разметки XAML, когда также предоставляется x:Class. Вместо создания разделяемого класса на основе класса страницы x:Class, предоставленный атрибут x:Class создается в качестве промежуточного класса, и затем предоставленный производный класс будет основываться на атрибуте x:Class.
Использование атрибута XAML
<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
...
</object>
Значения XAML
namespace |
Необязательный. Задает пространство имен среды CLR, содержащее параметр classname. Если задан параметр namespace, параметры namespace и classname разделяются точкой (.). |
classname |
Обязательный. Определяет имя CLR разделяемого класса, который связывает загруженный XAML и класс с выделенным кодом для этого XAML. См. примечания. |
subclassNamespace |
Необязательный. Может отличаться от параметра namespace, если каждое из пространств имен может разрешать другое. Задает пространство имен среды CLR, содержащее параметр subclassName. Если задан параметр subclassName, параметры subclassNamespace и subclassName разделяются точкой (.). |
subclassName |
Обязательный. Задает имя подкласса CLR. |
Зависимости
Директива x:Class также должен быть предоставлен в том же объекте, и этот объект должен быть корневым элементом создания XAML.
Заметки
Атрибут x:Subclass необходимо использовать в первую очередь для языков, которые не поддерживают объявление разделяемого класса.
Класс, используемый как x:Subclass, не может быть вложенным классом, а x:Subclass должен ссылаться на корневой объект, как описано в разделе "Зависимости".
В противном случае основное значение x:Subclass является неопределенным реализацией служб XAML .NET Framework. Это происходит потому, что поведение служб XAML .NET Framework не указывает общую модель программирования, которая используется для подключения разметки XAML и вспомогательного кода. Реализации дополнительных понятий, связанных с x:Class и x:Subclass, осуществляются конкретными платформами, которые используют модели программирования или модели приложений для определения способа соединения разметки XAML, скомпилированнной разметки и лежащего в их основе кода среды CLR. Каждая структура может иметь свои собственные действия построения, включающие некоторое поведение или отдельные компоненты, которые должны быть включены в среду построения. Внутри платформы действия построения также зависят от конкретного языка среды CLR, который используется для кода.
Примечания об использовании WPF
x:Subclass может находиться в корне страницы или в корне Application в определении приложения, которое уже имеет x:Class. Объявление x:Subclass на любом элементе, кроме корня страницы или приложения, или указание его там, где отсутствует атрибут x:Class, приводит к ошибке во время компиляции.
Создание производных классов, правильно работающих со скриптом x:Subclass, является довольно сложной задачей. Может потребоваться проверка промежуточных файлов (G-файлов, создаваемых в папке obj проекта в результате компиляции разметки, с именами, включающими имена XAML-файлов). Промежуточные файлы могут помочь определить происхождение отдельных программных конструкций в разделяемых классах внутри скомпилированного приложения.
Обработчики событий в производном классе должны быть internal override (Friend Overrides в Microsoft Visual Basic), чтобы переопределить заглушки для обработчиков при создании в промежуточном классе во время компиляции. В противном случае реализация производного класса скроет (затенит) реализацию промежуточного класса и обработчики промежуточного класса не будут вызываться.
При определении x:Class и x:Subclass необязательно предоставлять какую-либо реализацию класса, на который ссылается x:Class. Достаточно присвоить имя через атрибут x:Class, чтобы у компилятора были некоторые руководства по классу, который он создает в промежуточных файлах (в этом случае компилятор не выбирает имя по умолчанию). Можно предоставить реализацию классу x:Class; однако при одновременном использовании x:Class и x:Subclass такой подход используется редко.