Директива x:Subclass
Изменяет поведение компиляции разметки XAML, если x:Class
оно также указано. Вместо создания частичного класса, x:Class
основанного на , предоставленный x:Class
создается в качестве промежуточного класса, а затем предоставленный производный класс должен быть основан на x:Class
.
Использование атрибута XAML
<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
...
</object>
Значения XAML
Стоимость | Description |
---|---|
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. Это связано с тем, что поведение служб XAML .NET не указывает общую модель программирования, с помощью которой подключается разметка 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
.
См. также
.NET Desktop feedback