x:Subclass, dyrektywa

Artykuł
12/19/2024

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.

Udostępnij za pośrednictwem