Szczegóły składni XAML

Artykuł
07/13/2023

W tym temacie zdefiniowano terminy, które są używane do opisywania elementów składni XAML. Te terminy są często używane w pozostałej części tej dokumentacji, zarówno w przypadku dokumentacji WPF, jak i dla innych struktur korzystających z języka XAML lub podstawowych pojęć XAML włączonych przez obsługę języka XAML na poziomie System.Xaml. Ten temat rozszerza podstawową terminologię wprowadzoną w temacie XAML w WPF.

Specyfikacja języka XAML

Terminologia składni XAML zdefiniowana tutaj jest również zdefiniowana lub przywoływana w specyfikacji języka XAML. XAML to język oparty na kodzie XML i jest zgodny z regułami strukturalnymi XML lub rozwijany. Część terminologii jest udostępniana lub opiera się na terminologii często używanej podczas opisywania języka XML lub modelu obiektów dokumentów XML.

Aby uzyskać więcej informacji na temat specyfikacji języka XAML, pobierz plik [MS-XAML] z Centrum pobierania Microsoft.

XAML i CLR

XAML to język znaczników. Środowisko uruchomieniowe języka wspólnego (CLR), zgodnie z jego nazwą, umożliwia wykonywanie w czasie wykonywania. Język XAML nie jest sam w sobie jednym z popularnych języków, które są bezpośrednio używane przez środowisko uruchomieniowe CLR. Zamiast tego można traktować język XAML jako obsługę własnego systemu typów. Konkretny system analizy XAML używany przez WPF jest oparty na clR i systemie typów CLR. Typy XAML są mapowane na typy CLR w celu utworzenia wystąpienia reprezentacji czasu wykonywania, gdy kod XAML dla WPF jest analizowany. Z tego powodu pozostała część dyskusji na temat składni w tym dokumencie będzie zawierać odwołania do systemu typów CLR, mimo że równoważne dyskusje składni w specyfikacji języka XAML nie. (Na poziomie specyfikacji języka XAML typy XAML mogą być mapowane na dowolny inny system typów, który nie musi być CLR, ale wymagałoby to utworzenia i użycia innego analizatora XAML).

Elementy członkowskie typów i dziedziczenia klas

Właściwości i zdarzenia wyświetlane jako elementy członkowskie XAML typu WPF są często dziedziczone z typów podstawowych. Rozważmy na przykład następujący przykład: <Button Background="Blue" .../>. Właściwość Background nie jest natychmiast zadeklarowaną właściwością klasy Button , jeśli chcesz przejrzeć definicję klasy, wyniki odbicia lub dokumentację. Background Zamiast tego jest dziedziczony z klasy bazowejControl.

Zachowanie dziedziczenia klas elementów XAML WPF jest znaczącym odejściem od wymuszanej przez schemat interpretacji znaczników XML. Dziedziczenie klas może stać się złożone, szczególnie gdy pośrednie klasy bazowe są abstrakcyjne lub gdy są zaangażowane interfejsy. Jest to jeden z powodów, dla których zestaw elementów XAML i ich dopuszczalne atrybuty są trudne do reprezentowania dokładnie i całkowicie przy użyciu typów schematów, które są zwykle używane do programowania XML, takiego jak format DTD lub XSD. Innym powodem jest to, że rozszerzalność i cechy mapowania typów samego języka XAML uniemożliwiają kompletność dowolnej stałej reprezentacji dopuszczalnych typów i elementów członkowskich.

Składnia elementu object

Składnia elementu obiektu to składnia znaczników XAML, która tworzy wystąpienie klasy CLR lub struktury, deklarując element XML. Ta składnia przypomina składnię elementów innych języków znaczników, takich jak HTML. Składnia elementu obiektu zaczyna się od lewego nawiasu kątowego (<), po którym następuje natychmiast nazwa typu tworzonej klasy lub struktury. Zero lub więcej spacji może podążać za nazwą typu, a zero lub więcej atrybutów może być również zadeklarowanych w elemecie obiektu, z co najmniej jedną spacją oddzielającą każdą nazwę atrybutu="wartość" pary. Na koniec jedna z następujących wartości musi być prawdziwa:

Element i tag muszą być zamknięte ukośnikiem ukośnym (/), a następnie bezpośrednio nawiasem kątowym (>).
Tag otwierający musi zostać zakończony nawiasem kątowym (>). Inne elementy obiektu, elementy właściwości lub tekst wewnętrzny mogą być zgodne z tagiem otwierającym. Dokładnie zawartość, która może być zawarta w tym miejscu, jest zwykle ograniczona przez model obiektów elementu. Równoważny tag zamykający dla elementu obiektu musi również istnieć w odpowiednim zagnieżdżaniu i równoważeniu z innymi parami tagów otwierających i zamykających.

Język XAML implementowany przez platformę .NET zawiera zestaw reguł mapujących elementy obiektów na typy, atrybuty w właściwości lub zdarzenia oraz przestrzenie nazw XAML na przestrzenie nazw CLR oraz zestaw. W przypadku elementów obiektów WPF i .NET elementy obiektów XAML są mapowane na typy platformy .NET zgodnie z definicją w zestawach, a atrybuty są mapowane na elementy członkowskie tych typów. W przypadku odwołowania się do typu CLR w języku XAML masz również dostęp do odziedziczonych elementów członkowskich tego typu.

Na przykład poniższy przykład to składnia elementu obiektu, która tworzy wystąpienie nowego wystąpienia Button klasy, a także określa Name atrybut i wartość dla tego atrybutu:

<Button Name="CheckoutButton"/>

Poniższy przykład to składnia elementu obiektu, która zawiera również składnię właściwości zawartości XAML. Tekst wewnętrzny zawarty w pliku zostanie użyty do ustawienia TextBox właściwości zawartości XAML . Text

<TextBox>This is a Text Box</TextBox>

Modele zawartości

Klasa może obsługiwać użycie jako element obiektu XAML pod względem składni, ale ten element będzie działać prawidłowo tylko w aplikacji lub na stronie, gdy zostanie umieszczony w oczekiwanej pozycji ogólnego con tryb namiotu l lub drzewa elementów. Na przykład MenuItem element powinien być zwykle umieszczany tylko jako element podrzędny klasy pochodnej MenuBase , takiej jak Menu. Con tryb namiotu ls dla określonych elementów są udokumentowane w ramach uwag na stronach klasy dla kontrolek i innych klas WPF, które mogą być używane jako elementy XAML.

Właściwości elementów obiektu

Właściwości w języku XAML są ustawiane przez różne możliwe składnie. Składnia, która może być używana dla określonej właściwości, będzie się różnić w zależności od właściwości systemu typu bazowego ustawianej właściwości.

Ustawiając wartości właściwości, dodajesz funkcje lub cechy do obiektów, ponieważ istnieją one na wykresie obiektu czasu wykonywania. Początkowy stan utworzonego obiektu na podstawie elementu obiektu jest oparty na zachowaniu konstruktora bez parametrów. Zazwyczaj aplikacja będzie używać czegoś innego niż całkowicie domyślne wystąpienie dowolnego obiektu.

Składnia atrybutu (właściwości)

Składnia atrybutu to składnia znaczników XAML, która ustawia wartość dla właściwości, deklarując atrybut dla istniejącego elementu obiektu. Nazwa atrybutu musi być zgodna z nazwą składowej CLR właściwości klasy, która zwraca odpowiedni element obiektu. Po nazwie atrybutu następuje operator przypisania (=). Wartość atrybutu musi być ciągiem ujętym w cudzysłów.

Uwaga

Możesz użyć cudzysłowów naprzemiennych, aby umieścić znak cudzysłowu literału w atrybucie. Na przykład można użyć pojedynczych cudzysłowów jako środka, aby zadeklarować ciąg, który zawiera znak podwójnego cudzysłowu w nim. Niezależnie od tego, czy używasz cudzysłowów pojedynczych, czy podwójnych, należy użyć pary pasującej do otwierania i zamykania ciągu wartości atrybutu. Istnieją również sekwencje ucieczki lub inne techniki dostępne do pracy z ograniczeniami znaków narzuconymi przez dowolną konkretną składnię XAML. Zobacz Jednostki znaków XML i XAML.

Aby można było ustawić za pomocą składni atrybutu, właściwość musi być publiczna i musi być zapisywalna. Wartość właściwości w systemie typów kopii zapasowych musi być typem wartości lub musi być typem referencyjnym, do którego można utworzyć wystąpienie lub przywoływane przez procesor XAML podczas uzyskiwania dostępu do odpowiedniego typu kopii zapasowej.

W przypadku zdarzeń XAML WPF zdarzenie, do którego odwołuje się nazwa atrybutu, musi być publiczne i mieć delegata publicznego.

Właściwość lub zdarzenie musi być elementem członkowskim klasy lub struktury tworzonej przez element zawierający obiekt.

Przetwarzanie wartości atrybutów

Wartość ciągu zawarta w cudzysłowie otwierającym i zamykającym jest przetwarzana przez procesor XAML. W przypadku właściwości domyślne zachowanie przetwarzania jest określane przez typ podstawowej właściwości CLR.

Wartość atrybutu jest wypełniana przez jedną z następujących wartości przy użyciu tego zamówienia przetwarzania:

Jeśli procesor XAML napotka nawias klamrowy lub element obiektu, który pochodzi z MarkupExtensionklasy , to przywoływane rozszerzenie znaczników jest oceniane jako pierwszy, a nie przetwarzania wartości jako ciągu, a obiekt zwracany przez rozszerzenie znaczników jest używany jako wartość. W wielu przypadkach obiekt zwracany przez rozszerzenie znaczników będzie odwołaniem do istniejącego obiektu lub wyrażeniem, które odchyli ocenę do czasu wykonywania, i nie jest nowo utworzonym obiektem.
Jeśli właściwość jest zadeklarowana za pomocą atrybutu TypeConverter, lub typ wartości tej właściwości jest zadeklarowany z atrybutem , TypeConverterwartość ciągu atrybutu jest przesyłana do konwertera typów jako dane wejściowe konwersji, a konwerter zwróci nowe wystąpienie obiektu.
Jeśli nie TypeConverterma metody , zostanie podjęta bezpośrednia konwersja na typ właściwości. Ten ostatni poziom jest bezpośrednią konwersją na wartość natywną analizatora między typami pierwotnymi języka XAML lub sprawdzaniem nazw nazwanych stałych w wyliczenie (analizator uzyskuje dostęp do pasujących wartości).

Wartości atrybutów wyliczenia

Wyliczenia w języku XAML są przetwarzane wewnętrznie przez analizatory XAML, a elementy członkowskie wyliczenia należy określić, określając nazwę ciągu jednego z nazwanych stałych wyliczenia.

W przypadku wartości wyliczenia innych niż opóźnienie zachowanie natywne polega na przetwarzaniu ciągu wartości atrybutu i rozpoznawaniu go na jedną z wartości wyliczenia. Nie określasz wyliczenia w formacie Wyliczenie.Wartość, tak jak w kodzie. Zamiast tego należy określić tylko wartość, a wyliczenie jest wnioskowane przez typ ustawianej właściwości. Jeśli określisz atrybut w wyliczenie.Formularz wartości nie zostanie poprawnie rozpoznany.

W przypadku wyliczeń flagowych zachowanie jest oparte na metodzie Enum.Parse . Dla wyliczenia flagowego można określić wiele wartości, oddzielając każdą wartość przecinkami. Nie można jednak połączyć wartości wyliczenia, które nie są flagowe. Na przykład nie można użyć składni przecinka, aby spróbować utworzyć element Trigger , który działa na wielu warunkach wyliczenia innego niż opóźnienie:

<!--This will not compile, because Visibility is not a flagwise enumeration.-->  
...  
<Trigger Property="Visibility" Value="Collapsed,Hidden">  
  <Setter ... />  
</Trigger>  
...

Flagowe wyliczenia, które obsługują atrybuty, które są ustawiane w języku XAML, są rzadkie w WPF. Jednak jednym z takich wyliczeń jest StyleSimulations. Można na przykład użyć składni atrybutu rozdzielanego przecinkami, aby zmodyfikować przykład podany w uwagach dla Glyphs klasy . StyleSimulations = "BoldSimulation"StyleSimulations = "BoldSimulation,ItalicSimulation" KeyBinding.Modifiers jest inną właściwością, w której można określić więcej niż jedną wartość wyliczenia. Jednak ta właściwość ma szczególny przypadek, ponieważ ModifierKeys wyliczenie obsługuje własny konwerter typów. Konwerter typów modyfikatorów używa znaku plus (+) jako ogranicznika, a nie przecinka (,). Ta konwersja obsługuje bardziej tradycyjną składnię do reprezentowania kombinacji klawiszy w programowaniu systemu Microsoft Windows, takich jak "Ctrl+Alt".

Właściwości i odwołania do nazwy elementu członkowskiego zdarzenia

Podczas określania atrybutu można odwołać się do dowolnej właściwości lub zdarzenia, które istnieje jako element członkowski typu CLR utworzonego dla elementu zawierającego obiekt.

Można też odwołać się do dołączonej właściwości lub dołączonego zdarzenia niezależnie od elementu zawierającego obiekt. (Dołączone właściwości zostały omówione w nadchodzącej sekcji).

Można również nazwać dowolne zdarzenie z dowolnego obiektu, który jest dostępny za pośrednictwem domyślnej przestrzeni nazw przy użyciu typeName.częściowo kwalifikowana nazwa zdarzenia ; ta składnia obsługuje dołączanie programów obsługi dla zdarzeń kierowanych, w których program obsługi ma obsługiwać routing zdarzeń z elementów podrzędnych, ale element nadrzędny nie ma również tego zdarzenia w tabeli elementów członkowskich. Ta składnia przypomina dołączoną składnię zdarzenia, ale to zdarzenie nie jest prawdziwym dołączonym zdarzeniem. Zamiast tego odwołujesz się do zdarzenia o kwalifikowanej nazwie. Aby uzyskać więcej informacji, zobacz Omówienie zdarzeń trasowanych.

W niektórych scenariuszach nazwy właściwości są czasami podawane jako wartość atrybutu, a nie nazwa atrybutu. Nazwa właściwości może również zawierać kwalifikatory, takie jak właściwość określona w formularzu ownerType.dependencyPropertyName. Ten scenariusz jest typowy podczas pisania stylów lub szablonów w języku XAML. Reguły przetwarzania nazw właściwości podane jako wartość atrybutu są różne i podlegają typowi ustawianej właściwości lub zachowaniom określonych podsystemów WPF. Aby uzyskać szczegółowe informacje, zobacz Styling and Templating (Stylowanie i tworzenie szablonów).

Innym użyciem nazw właściwości jest to, gdy wartość atrybutu opisuje relację właściwości-właściwość. Ta funkcja jest używana do tworzenia powiązań danych i elementów docelowych scenorysu oraz jest włączana przez klasę PropertyPath i jej konwerter typów. Aby uzyskać bardziej szczegółowy opis semantyki odnośników, zobacz PropertyPath XAML Syntax (Składnia XAML obiektu PropertyPath).

Składnia elementu właściwości

Składnia elementu właściwości to składnia , która różni się nieco od podstawowych reguł składni XML dla elementów. W formacie XML wartość atrybutu jest de facto ciągiem, a jedyną możliwą odmianą jest używany format kodowania ciągów. W języku XAML można przypisać inne elementy obiektu jako wartość właściwości. Ta funkcja jest włączona przez składnię elementu właściwości. Zamiast właściwości określanej jako atrybut w tagu elementu, właściwość jest określana przy użyciu otwierającego tagu elementu w elementTypeName.propertyName formularza, wartość właściwości jest określona w obrębie, a następnie element właściwości jest zamknięty.

W szczególności składnia zaczyna się od lewego nawiasu kątowego (<), po którym następuje natychmiast nazwa typu klasy lub struktury, w której znajduje się składnia elementu właściwości. Następuje to natychmiast przez pojedynczą kropkę (.), a następnie przez nazwę właściwości, a następnie za pomocą prawego nawiasu kątowego (>). Podobnie jak w przypadku składni atrybutu, ta właściwość musi istnieć w zadeklarowanych publicznych elementach członkowskich określonego typu. Wartość, która ma zostać przypisana do właściwości, jest zawarta w elemecie właściwości. Zazwyczaj wartość jest podawana jako co najmniej jeden element obiektu, ponieważ określenie obiektów jako wartości jest scenariuszem, w jakim składnia elementu właściwości ma na celu rozwiązanie problemu. Na koniec równoważny tag zamykający określający ten sam elementTypeName.Należy podać kombinację propertyName , w odpowiednim zagnieżdżaniu i równoważeniu z innymi tagami elementów.

Na przykład poniżej przedstawiono składnię elementu właściwości dla ContextMenu właściwości Button.

<Button>
  <Button.ContextMenu>
    <ContextMenu>
      <MenuItem Header="1">First item</MenuItem>
      <MenuItem Header="2">Second item</MenuItem>
    </ContextMenu>
  </Button.ContextMenu>
  Right-click me!</Button>

Wartość elementu właściwości może być również podana jako tekst wewnętrzny, w przypadkach, gdy określony typ właściwości jest typem wartości pierwotnej, takim jak String, lub wyliczenie, w którym określono nazwę. Te dwa zastosowania są nieco nietypowe, ponieważ każdy z tych przypadków może również używać prostszej składni atrybutów. Jednym ze scenariuszy wypełniania elementu właściwości ciągiem jest zastosowanie właściwości, które nie są właściwością zawartości XAML, ale nadal są używane do reprezentacji tekstu interfejsu użytkownika, a konkretne elementy odstępu, takie jak kanały wiersza, są wymagane do wyświetlenia w tym tekście interfejsu użytkownika. Składnia atrybutów nie może zachować kanałów wiersza, ale składnia elementu właściwości może, tak długo, jak znaczące zachowanie białych znaków jest aktywne (aby uzyskać szczegółowe informacje, zobacz Przetwarzanie białych znaków w języku XAML). Innym scenariuszem jest to, że do elementu właściwości można zastosować dyrektywę x:Uid, a tym samym oznaczyć wartość w postaci wartości, która powinna być zlokalizowana w danych wyjściowych WPF BAML lub innych technik.

Element właściwości nie jest reprezentowany w drzewie logicznym WPF. Element właściwości to tylko określona składnia ustawiania właściwości i nie jest elementem, który zawiera wystąpienie lub obiekt, który go wspiera. (Aby uzyskać szczegółowe informacje na temat koncepcji drzewa logicznego, zobacz Drzewa w WPF).

W przypadku właściwości, w których obsługiwana jest składnia atrybutu i elementu właściwości, dwie składnie zazwyczaj mają ten sam wynik, chociaż subtelności, takie jak obsługa białych znaków, mogą się nieznacznie różnić w zależności od składni.

Składnia kolekcji

Specyfikacja XAML wymaga implementacji procesora XAML w celu zidentyfikowania właściwości, w których typ wartości jest kolekcją. Ogólna implementacja procesora XAML na platformie .NET jest oparta na kodzie zarządzanym i środowisku CLR oraz identyfikuje typy kolekcji za pomocą jednej z następujących metod:

Typ implementuje IListwartość .
Typ implementuje IDictionarywartość .
Typ pochodzi z Array (aby uzyskać więcej informacji na temat tablic w języku XAML, zobacz x:Array Markup Extension).

Jeśli typ właściwości jest kolekcją, wywnioskowany typ kolekcji nie musi być określony w znaczniku jako element obiektu. Zamiast tego elementy, które mają stać się elementami w kolekcji, są określane jako co najmniej jeden element podrzędny elementu właściwości. Każdy taki element jest oceniany na obiekt podczas ładowania i dodawany do kolekcji przez wywołanie Add metody kolekcji implikowanej. Na przykład Triggers właściwość przyjmuje wyspecjalizowany Style typ TriggerCollectionkolekcji , który implementuje IListelement . Nie jest konieczne utworzenie wystąpienia TriggerCollection elementu obiektu w adiustacji. Zamiast tego należy określić co najmniej jeden Trigger element jako elementy w Style.Triggers elemencie właściwości, gdzie Trigger (lub klasa pochodna) jest typem oczekiwanym jako typ elementu silnie typizowanego i niejawnego TriggerCollection.

<Style x:Key="SpecialButton" TargetType="{x:Type Button}">
  <Style.Triggers>
    <Trigger Property="Button.IsMouseOver" Value="true">
      <Setter Property = "Background" Value="Red"/>
    </Trigger>
    <Trigger Property="Button.IsPressed" Value="true">
      <Setter Property = "Foreground" Value="Green"/>
    </Trigger>
  </Style.Triggers>
</Style>

Właściwość może być zarówno typem kolekcji, jak i właściwością zawartości XAML dla tego typu i typów pochodnych, które zostały omówione w następnej sekcji tego tematu.

Niejawny element kolekcji tworzy element członkowski w reprezentacji drzewa logicznego, mimo że nie jest wyświetlany w znaczników jako element. Zwykle konstruktor typu nadrzędnego wykonuje wystąpienie kolekcji, która jest jedną z jego właściwości, a początkowo pusta kolekcja staje się częścią drzewa obiektów.

Uwaga

Interfejsy listy ogólnej i słownika (IList<T> i IDictionary<TKey,TValue>) nie są obsługiwane do wykrywania kolekcji. Można jednak użyć List<T> klasy jako klasy bazowej, ponieważ implementuje ją bezpośrednio lub Dictionary<TKey,TValue> jako klasę bazową, ponieważ implementuje IList IDictionary ją bezpośrednio.

Na stronach referencyjnych platformy .NET dla typów kolekcji ta składnia z celowym pominięciem elementu obiektu dla kolekcji jest od czasu do czasu zanotowana w sekcjach składni XAML jako Składnia niejawnej kolekcji.

Z wyjątkiem elementu głównego każdy element obiektu w pliku XAML, który jest zagnieżdżony jako element podrzędny innego elementu, jest naprawdę elementem, który jest jednym lub oba z następujących przypadków: elementem niejawnym właściwości kolekcji elementu nadrzędnego lub elementem określającym wartość właściwości zawartości XAML dla elementu nadrzędnego (właściwości zawartości XAML zostaną omówione w nadchodzącej sekcji). Innymi słowy, relacja elementów nadrzędnych i elementów podrzędnych na stronie znaczników jest naprawdę pojedynczym obiektem w katalogu głównym, a każdy element obiektu pod katalogiem głównym jest albo pojedynczym wystąpieniem, które zapewnia wartość właściwości elementu nadrzędnego, lub jeden z elementów w kolekcji, który jest również wartością właściwości typu kolekcji elementu nadrzędnego. Ta pojedyncza koncepcja jest powszechna w przypadku kodu XML i jest często wzmacniana w zachowaniu interfejsów API ładujących kod XAML, takich jak Load.

Poniższy przykład to składnia z elementem object dla kolekcji (GradientStopCollection) określonej jawnie.

<LinearGradientBrush>  
  <LinearGradientBrush.GradientStops>  
    <GradientStopCollection>  
      <GradientStop Offset="0.0" Color="Red" />  
      <GradientStop Offset="1.0" Color="Blue" />  
    </GradientStopCollection>  
  </LinearGradientBrush.GradientStops>  
</LinearGradientBrush>

Należy pamiętać, że nie zawsze można jawnie zadeklarować kolekcję. Na przykład próba jawnego zadeklarowania TriggerCollection w przedstawionym wcześniej przykładzie Triggers zakończy się niepowodzeniem. Jawne deklarowanie kolekcji wymaga, aby klasa kolekcji obsługiwała konstruktor bez parametrów i TriggerCollection nie ma konstruktora bez parametrów.

Właściwości zawartości XAML

Składnia zawartości XAML jest składnią, która jest włączona tylko w klasach, które określają ContentPropertyAttribute jako część deklaracji klasy. Odwołuje ContentPropertyAttribute się do nazwy właściwości, która jest właściwością zawartości dla tego typu elementu (w tym klas pochodnych). Podczas przetwarzania przez procesor XAML wszystkie elementy podrzędne lub tekst wewnętrzny znalezione między tagami otwierania i zamykania elementu obiektu zostaną przypisane jako wartość właściwości zawartości XAML dla tego obiektu. Można określić jawne elementy właściwości dla właściwości zawartości, ale to użycie nie jest ogólnie wyświetlane w sekcjach składni XAML w dokumentacji platformy .NET. Technika jawna/szczegółowa ma okazjonalną wartość jasności znaczników lub jako kwestię stylu znaczników, ale zwykle intencją właściwości zawartości jest usprawnienie adiustacji, aby elementy, które są intuicyjnie powiązane jako element nadrzędny-podrzędny, mogą być zagnieżdżone bezpośrednio. Tagi elementów właściwości dla innych właściwości elementu nie są przypisywane jako "zawartość" dla ścisłej definicji języka XAML; są one przetwarzane wcześniej w kolejności przetwarzania analizatora XAML i nie są uważane za "zawartość".

Wartości właściwości zawartości XAML muszą być ciągłe

Wartość właściwości zawartości XAML musi być podana całkowicie przed lub całkowicie po innych elementach właściwości w tym elemecie obiektu. Jest to prawda, czy wartość właściwości zawartości XAML jest określona jako ciąg, czy jako co najmniej jeden obiekt. Na przykład następujące znaczniki nie analizują:

<Button>I am a
  <Button.Background>Blue</Button.Background>  
  blue button</Button>

Jest to niedozwolone, ponieważ jeśli ta składnia została jawna przy użyciu składni elementu właściwości dla właściwości content, właściwość zawartości zostanie ustawiona dwukrotnie:

<Button>  
  <Button.Content>I am a </Button.Content>  
  <Button.Background>Blue</Button.Background>  
  <Button.Content> blue button</Button.Content>  
</Button>

Podobnie nielegalny przykład polega na tym, że właściwość zawartości jest kolekcją, a elementy podrzędne są przeplatane elementami właściwości:

<StackPanel>  
  <Button>This example</Button>  
  <StackPanel.Resources>  
    <SolidColorBrush x:Key="BlueBrush" Color="Blue"/>  
  </StackPanel.Resources>  
  <Button>... is illegal XAML</Button>  
</StackPanel>

Właściwości zawartości i składnia kolekcji połączone

Aby zaakceptować więcej niż jeden element obiektu jako zawartość, typ właściwości zawartości musi być w szczególności typem kolekcji. Podobnie jak składnia elementu właściwości dla typów kolekcji, procesor XAML musi identyfikować typy, które są typami kolekcji. Jeśli element ma właściwość zawartości XAML, a typ właściwości zawartości XAML jest kolekcją, typ kolekcji implikowanej nie musi być określony w znaczniku jako element obiektu, a właściwość zawartości XAML nie musi być określona jako element właściwości. W związku z tym widoczny con tryb namiotu l w adiustacji może teraz mieć więcej niż jeden element podrzędny przypisany jako zawartość. Poniżej znajduje się składnia zawartości dla klasy pochodnej Panel . Wszystkie Panel klasy pochodne określają właściwość zawartości XAML na Children, która wymaga wartości typu UIElementCollection.

<Page
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  >
  <StackPanel>
    <Button>Button 1</Button>
    <Button>Button 2</Button>
    <Button>Button 3</Button>
  </StackPanel>
</Page>

Należy pamiętać, że ani element właściwości , Children ani element dla UIElementCollection elementu nie są wymagane w adiustacji. Jest to funkcja projektowania języka XAML, dzięki czemu cyklicznie zawarte elementy, które definiują interfejs użytkownika, są bardziej intuicyjnie reprezentowane jako drzewo zagnieżdżonych elementów z bezpośrednimi relacjami elementów nadrzędny-podrzędny bez pośrednicstwa tagów elementów właściwości lub obiektów kolekcji. W rzeczywistości UIElementCollection nie można jawnie określić w adiustacji jako elementu obiektu zgodnie z projektem. Ponieważ jego jedynym zamierzonym zastosowaniem jest niejawna kolekcja, UIElementCollection nie uwidacznia publicznego konstruktora bez parametrów i w związku z tym nie można utworzyć wystąpienia jako elementu obiektu.

Mieszanie elementów właściwości i elementów obiektu w obiekcie z właściwością content

Specyfikacja XAML deklaruje, że procesor XAML może wymusić, że elementy obiektów używane do wypełnienia właściwości zawartości XAML w elemmencie obiektu muszą być ciągłe i nie mogą być mieszane. To ograniczenie mieszania elementów właściwości i zawartości jest wymuszane przez procesory XAML WPF.

Element obiektu podrzędnego może być pierwszym bezpośrednim znacznikiem w elemecie object. Następnie można wprowadzić elementy właściwości. Możesz też określić co najmniej jeden element właściwości, a następnie zawartość, a następnie więcej elementów właściwości. Ale gdy element właściwości jest zgodny z zawartością, nie można wprowadzić żadnej dalszej zawartości, można dodać tylko elementy właściwości.

To wymaganie kolejności elementów zawartości/właściwości nie ma zastosowania do tekstu wewnętrznego używanego jako zawartość. Jednak nadal jest to dobry styl znaczników, aby zachować ciągły tekst wewnętrzny, ponieważ znaczące białe znaki będą trudne do wykrycia wizualnego w znaczniku, jeśli elementy właściwości są przeplatane tekstem wewnętrznym.

Przestrzeń nazw XAML

Żaden z powyższych przykładów składni nie określił przestrzeni nazw XAML innej niż domyślna przestrzeń nazw XAML. W typowych aplikacjach WPF domyślna przestrzeń nazw XAML jest określona jako przestrzeń nazw WPF. Możesz określić przestrzenie nazw XAML inne niż domyślna przestrzeń nazw XAML i nadal używać podobnej składni. Jednak w dowolnym miejscu, w którym klasa ma nazwę, która nie jest dostępna w domyślnej przestrzeni nazw XAML, ta nazwa klasy musi być poprzedzona prefiksem przestrzeni nazw XAML jako zamapowanego na odpowiadającą przestrzeń nazw CLR. Na przykład <custom:Example/> jest składnią elementu obiektu w celu utworzenia wystąpienia wystąpienia Example klasy, w którym przestrzeń nazw CLR zawierająca tę klasę (i ewentualnie informacje o zestawie zewnętrznym, które zawierają typy kopii zapasowych) została wcześniej zamapowana na custom prefiks.

Aby uzyskać więcej informacji na temat przestrzeni nazw XAML, zobacz Przestrzenie nazw XAML i Mapowanie przestrzeni nazw dla WPF XAML.

Rozszerzenia struktury znaczników

Język XAML definiuje jednostkę programowania rozszerzenia znaczników, która umożliwia ucieczkę od normalnego procesora XAML obsługującego wartości atrybutów ciągów lub elementów obiektu, a także odchyla przetwarzanie do klasy zapasowej. Znak, który identyfikuje rozszerzenie znaczników do procesora XAML w przypadku używania składni atrybutu, to otwierający nawias klamrowy ({), po którym następuje dowolny znak inny niż zamykający nawias klamrowy (}). Pierwszy ciąg po otwierającym nawiasie klamrowym musi odwoływać się do klasy, która zapewnia określone zachowanie rozszerzenia, gdzie odwołanie może pominąć podciąg "Rozszerzenie", jeśli podciąg jest częścią prawdziwej nazwy klasy. Następnie może pojawić się pojedyncze miejsce, a następnie każdy znak powodzenia jest używany jako dane wejściowe przez implementację rozszerzenia, aż do napotkania zamykającego nawiasu klamrowego.

Implementacja XAML platformy .NET używa MarkupExtension klasy abstrakcyjnej jako podstawy dla wszystkich rozszerzeń znaczników obsługiwanych przez WPF, a także innych struktur lub technologii. Rozszerzenia znaczników, które w szczególności implementuje WPF, są często przeznaczone do zapewnienia środków do odwołowania się do innych istniejących obiektów lub do odroczonych odwołań do obiektów, które będą oceniane w czasie wykonywania. Na przykład proste powiązanie danych WPF jest realizowane przez określenie {Binding} rozszerzenia znaczników zamiast wartości, którą zwykle będzie przyjmować określona właściwość. Wiele rozszerzeń znaczników WPF umożliwia składnię atrybutu dla właściwości, w których składnia atrybutu nie byłaby w przeciwnym razie możliwa. Na przykład Style obiekt jest stosunkowo złożonym typem zawierającym zagnieżdżonych serii obiektów i właściwości. Style w WPF są zwykle definiowane jako zasób w elemencie ResourceDictionary, a następnie odwoływali się do jednego z dwóch rozszerzeń znaczników WPF, które żądają zasobu. Rozszerzenie znaczników odwraca ocenę wartości właściwości do wyszukiwania zasobów i umożliwia podanie wartości Style właściwości, biorąc typ Style, w składni atrybutu, jak w poniższym przykładzie:

<Button Style="{StaticResource MyStyle}">My button</Button>

StaticResource W tym miejscu identyfikuje klasę StaticResourceExtension zapewniającą implementację rozszerzenia znaczników. Następny ciąg MyStyle jest używany jako dane wejściowe dla konstruktora innego niż domyślny StaticResourceExtension , gdzie parametr jako pobrany z ciągu rozszerzenia deklaruje żądany ResourceKeyelement . MyStylewartość x:Key zdefiniowana Style jako zasób powinna być wartością x:Key. Użycie rozszerzenia StaticResource Markup żąda, aby zasób był używany do udostępniania Style wartości właściwości za pomocą logiki wyszukiwania zasobów statycznych w czasie ładowania.

Aby uzyskać więcej informacji na temat rozszerzeń znaczników, zobacz Rozszerzenia znaczników i WPF XAML. Aby zapoznać się z dokumentacją rozszerzeń znaczników i innymi funkcjami programowania XAML włączonymi w ogólnej implementacji języka XAML platformy .NET, zobacz Funkcje języka XAML (x:). Aby zapoznać się z rozszerzeniami znaczników specyficznych dla platformy WPF, zobacz Rozszerzenia XAML platformy WPF.

Dołączone właściwości

Dołączone właściwości to koncepcja programowania wprowadzona w języku XAML, w której właściwości mogą być własnością i definiowane przez określony typ, ale ustawiane jako atrybuty lub elementy właściwości na dowolnym elemenie. Podstawowym scenariuszem, dla którego są dołączone właściwości, jest włączenie elementów podrzędnych w strukturze znaczników w celu raportowania informacji do elementu nadrzędnego bez konieczności szerokiego współużytkowanego modelu obiektów we wszystkich elementach. Z drugiej strony dołączone właściwości mogą być używane przez elementy nadrzędne do zgłaszania informacji do elementów podrzędnych. Aby uzyskać więcej informacji na temat przeznaczenia dołączonych właściwości i sposobu tworzenia własnych dołączonych właściwości, zobacz Omówienie dołączonych właściwości.

Dołączone właściwości używają składni, która powierzchownie przypomina składnię elementu właściwości, w tym należy również określić typeName.kombinacja propertyName . Istnieją dwie ważne różnice:

Możesz użyć atrybutu typeName.propertyName kombinacja nawet podczas ustawiania dołączonej właściwości za pomocą składni atrybutu. Dołączone właściwości są jedynym przypadkiem, w którym kwalifikowanie nazwy właściwości jest wymaganiem w składni atrybutu.
Można również użyć składni elementu właściwości dla dołączonych właściwości. Jednak w przypadku typowej składni elementu właściwości określony typeName jest elementem obiektu, który zawiera element właściwości. Jeśli odwołujesz się do dołączonej właściwości, typeName jest klasą, która definiuje dołączoną właściwość, a nie element obiektu zawierającego.

Dołączone zdarzenia

Dołączone zdarzenia to kolejna koncepcja programowania wprowadzona w języku XAML, w której zdarzenia mogą być definiowane przez określony typ, ale programy obsługi mogą być dołączone do dowolnego elementu obiektu. W implementacji funkcji WOF często typ definiujący dołączone zdarzenie jest typem statycznym definiującym usługę, a czasami te dołączone zdarzenia są udostępniane przez alias zdarzenia kierowanego w typach, które uwidaczniają usługę. Procedury obsługi dołączonych zdarzeń są określane za pomocą składni atrybutów. Podobnie jak w przypadku dołączonych zdarzeń składnia atrybutów jest rozszerzana dla dołączonych zdarzeń, aby zezwolić na typName.eventName usage, gdzie typeName jest klasą, która udostępnia Add i Remove procedury obsługi zdarzeń dla dołączonej infrastruktury zdarzeń, a eventName jest nazwą zdarzenia.

Anatomia elementu głównego XAML

W poniższej tabeli przedstawiono typowy element główny XAML podzielony na poszczególne atrybuty elementu głównego:

Atrybut	opis
`<Page`	Otwieranie elementu obiektu głównego
`xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"`	Domyślna przestrzeń nazw XAML (WPF)
`xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"`	Przestrzeń nazw XAML języka XAML
`x:Class="ExampleNamespace.ExampleCode"`	Deklaracja klasy częściowej, która łączy znaczniki z dowolnym kodem zdefiniowanym dla klasy częściowej
`>`	Koniec elementu obiektu dla katalogu głównego. Obiekt nie został jeszcze zamknięty, ponieważ element zawiera elementy podrzędne

Opcjonalne i nierozpoznane użycie kodu XAML

W poniższych sekcjach opisano użycie języka XAML, które są technicznie obsługiwane przez procesory XAML, ale generują one szczegółowość lub inne problemy estetyczne, które zakłócają działanie plików XAML, które pozostają czytelne dla człowieka podczas tworzenia aplikacji zawierających źródła XAML.

Opcjonalne użycie elementu właściwości

Opcjonalne użycie elementu właściwości obejmuje jawne zapisywanie właściwości zawartości elementu, które procesor XAML uznaje za niejawne. Na przykład w przypadku deklarowania zawartości Menuobiektu można jawnie zadeklarować Items kolekcję Menu jako <Menu.Items> tag elementu właściwości, a następnie umieścić poszczególne MenuItem elementy w <Menu.Items>obiekcie zamiast używać niejawnego zachowania procesora XAML, że wszystkie elementy Menu podrzędne elementu muszą być elementami MenuItem i są umieszczane w Items kolekcji. Czasami opcjonalne użycie może pomóc wizualnie wyjaśnić strukturę obiektów reprezentowaną w adiustacji. Czasami jawne użycie elementu właściwości może uniknąć znaczników, które jest technicznie funkcjonalne, ale wizualnie mylące, takie jak zagnieżdżone rozszerzenia znaczników w ramach wartości atrybutu.

Atrybuty kwalifikowane Full typeName.memberName

TypeName.Formularz memberName atrybutu działa faktycznie bardziej uniwersalnie niż tylko przypadek zdarzenia kierowanego. Ale w innych sytuacjach, że formularz jest zbędny i należy go unikać, jeśli tylko ze względu na styl znaczników i czytelność. W poniższym przykładzie każde z trzech odwołań do atrybutu Background jest całkowicie równoważne:

<Button Background="Blue">Background</Button>
<Button Button.Background="Blue">Button.Background</Button>
<Button Control.Background="Blue">Control.Background</Button>

Button.Background Działa, ponieważ kwalifikowane wyszukiwanie dla tej właściwości dla tej właściwości Button powiodło się (Background zostało odziedziczone z kontrolki) i Button jest klasą elementu obiektu lub klasy bazowej. Control.Background działa, ponieważ Control klasa faktycznie definiuje Background i Control jest klasą bazową Button .

Jednak następujący typName.Przykład formularza memberName nie działa i dlatego jest wyświetlany komentarz:

<!--<Button Label.Background="Blue">Does not work</Button> -->

Labeljest inną klasą pochodną Control Label klasy , a jeśli określono Label.Background element obiektu, to użycie zadziałałoby. Jednak ponieważ Label nie jest klasą lub klasą Buttonbazową klasy , określone zachowanie procesora XAML jest następnie przetwarzane Label.Background jako dołączona właściwość. Label.Background nie jest dostępną dołączoną właściwością, a to użycie kończy się niepowodzeniem.

baseTypeName.memberName, elementy właściwości

W sposób analogiczny do sposobu, w jaki typeName.Formularz memberName działa dla składni atrybutów , baseTypeName.Składnia memberName działa dla składni elementu właściwości. Na przykład działa następująca składnia:

<Button>Control.Background PE
  <Control.Background>
    <LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
      <GradientStop Color="Yellow" Offset="0.0" />
      <GradientStop Color="LimeGreen" Offset="1.0" />
    </LinearGradientBrush>
    </Control.Background>
</Button>

W tym miejscu element właściwości został podany tak, jakby Control.Background element właściwości był zawarty w elemecie Button.

Ale podobnie jak typeName.formularz memberName dla atrybutów, baseTypeName.memberName jest słaby styl w adiustacji i należy go unikać.

Udostępnij za pośrednictwem