Udostępnij za pośrednictwem


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:Classmetodzie , 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ą classnameelement . 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ą subclassNameelement . 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:Classx: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:Classjuż 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:Subclassnie trzeba dostarczać żadnej implementacji dla klasy, x:Classdo 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ż