x:Subclass — dyrektywa
Modyfikuje zachowanie kompilowania znaczników XAML, jeśli x:Class
jest również udostępniane. Zamiast tworzyć klasę częściową opartą na x:Class
metodzie , podana x:Class
klasa jest tworzona jako klasa pośrednia, a następnie oczekiwana klasa pochodna będzie oparta na .x:Class
Użycie atrybutu języka XAML
<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
...
</object>
Wartości XAML
Wartość | Opis |
---|---|
namespace |
Opcjonalny. Określa przestrzeń nazw CLR zawierającą classname element . Jeśli namespace zostanie określony, kropka (.) oddziela namespace wartości i classname . |
classname |
Wymagane. Określa nazwę CLR klasy częściowej, która łączy załadowany kod XAML i kod-behind dla tego XAML. Zobacz uwagi. |
subclassNamespace |
Opcjonalny. Może się różnić od namespace tego, czy każda przestrzeń nazw może rozpoznać drugą. Określa przestrzeń nazw CLR zawierającą subclassName element . Jeśli subclassName zostanie określony, kropka (.) oddziela subclassNamespace wartości i subclassName . |
subclassName |
Wymagane. Określa nazwę CLR podklasy. |
Zależności
x:Dyrektywa klasy musi być również podana na tym samym obiekcie, a ten obiekt musi być elementem głównym produkcji XAML.
Uwagi
x:Subclass
użycie jest przeznaczone głównie dla języków, które nie obsługują deklaracji klas częściowych.
Klasa używana jako x:Subclass
klasa nie może być klasą zagnieżdżona i x:Subclass
musi odwoływać się do obiektu głównego zgodnie z opisem w sekcji "Zależności".
W przeciwnym razie pojęcie pojęcia x:Subclass
jest niezdefiniowane przez implementację usług XAML platformy .NET. Dzieje się tak, ponieważ zachowanie usług XAML platformy .NET nie określa ogólnego modelu programowania, za pomocą którego są połączone znaczniki XAML i kod zapasowy. Implementacje dalszych pojęć związanych z x:Class
x:Subclass
i są wykonywane przez określone struktury, które używają modeli programowania lub modeli aplikacji do definiowania sposobu łączenia znaczników XAML, skompilowanego znaczników i kodu opartego na clR. Każda struktura może mieć własne akcje kompilacji, które umożliwiają niektóre zachowania lub określone składniki, które muszą być uwzględnione w środowisku kompilacji. W ramach platformy akcje kompilacji mogą również różnić się w zależności od określonego języka CLR używanego dla kodu.
Uwagi dotyczące użycia platformy WPF
x:Subclass
może znajdować się w katalogu głównym strony lub w Application katalogu głównym w definicji aplikacji, która ma x:Class
już wartość . Deklarowanie x:Subclass
elementu innego niż strona lub katalog główny aplikacji lub określanie go tam, gdzie nie x:Class
istnieje, powoduje błąd czasu kompilacji.
Tworzenie klas pochodnych, które działają poprawnie dla scenariusza x:Subclass
, jest dość złożone. Może być konieczne sprawdzenie plików pośrednich (pliki g utworzone w folderze obj projektu przez kompilację znaczników z nazwami zawierającymi nazwy plików xaml). Te pliki pośrednie mogą pomóc w ustaleniu pochodzenia niektórych konstrukcji programowania w sprzężonych klasach częściowych w skompilowanej aplikacji.
Programy obsługi zdarzeń w klasie pochodnej muszą mieć internal override
wartość (Friend Overrides
w języku Microsoft Visual Basic), aby zastąpić wycinki procedur obsługi utworzonych w klasie pośredniej podczas kompilacji. W przeciwnym razie implementacje klas pochodnych ukrywają implementację klasy pośredniej (cień), a programy obsługi klasy pośredniej nie są wywoływane.
Podczas definiowania parametrów x:Class
i x:Subclass
nie trzeba dostarczać żadnej implementacji dla klasy, x:Class
do której odwołuje się element . Wystarczy podać nazwę za pomocą atrybutu x:Class
, aby kompilator miał wskazówki dotyczące klasy tworzonej w plikach pośrednich (kompilator nie wybiera w tym przypadku nazwy domyślnej). Można nadać x:Class
klasie implementację, jednak nie jest to typowy scenariusz użycia zarówno metody , jak x:Class
i x:Subclass
.
Zobacz też
.NET Desktop feedback