Udostępnij za pośrednictwem

x:Subclass, dyrektywa

Modyfikuje zachowanie kompilowania znaczników XAML po udostępnieniu x:Class. Zamiast tworzyć klasę częściową opartą na x:Class, podana x:Class jest tworzona jako klasa pośrednia, a następnie oczekiwana klasa pochodna będzie oparta na x:Class.

Użycie atrybutu XAML

<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
   ...
</object>

Wartości XAML

Wartość Opis
namespace Fakultatywny. Określa przestrzeń nazw CLR zawierającą classname. Jeśli określono namespace, kropka (.) oddziela namespace 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 Fakultatywny. Może się różnić od namespace, jeśli każda przestrzeń nazw może rozpoznać drugą. Określa przestrzeń nazw CLR zawierającą subclassName. Jeśli określono subclassName, kropka (.) oddziela subclassNamespace i subclassName.
subclassName Wymagane. Określa nazwę CLR podklasy.

Zależności

x:Klasa Dyrektywy 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 nie może być klasą zagnieżdżona, a x:Subclass musi odwoływać się do obiektu głównego, jak wyjaśniono w sekcji "Zależności".

W przeciwnym razie pojęcie 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 i x:Subclass są wykonywane przez określone struktury korzystające z modeli programowania lub modeli aplikacji w celu zdefiniowania sposobu łączenia znaczników XAML, skompilowanych 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 katalogu głównym Application w definicji aplikacji, która ma już x:Class. Deklarowanie x:Subclass na dowolnym elemenie innym niż strona lub katalog główny aplikacji albo określanie, gdzie nie istnieje x:Class, 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ą być internal override (Friend Overrides w programie 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 zarówno x:Class, jak i x:Subclassnie trzeba udostępniać żadnej implementacji dla klasy, do której odwołuje się x:Class. Wystarczy nadać mu nazwę za pośrednictwem atrybutu x:Class, aby kompilator miał pewne 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 implementacji; jednak nie jest to typowy scenariusz użycia zarówno x:Class, jak i x:Subclass.

Zobacz też