Szczegóły składni XAML

W tym temacie zdefiniowano terminy 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 dla dokumentacji WPF, jak i dla innych platform, które używają języka XAML, lub podstawowych pojęć XAML włączonych przez obsługę języka XAML na poziomie System.Xaml. W tym temacie rozszerzono podstawową terminologię wprowadzona w temacie XAML w WPF.

W tym temacie zdefiniowano terminy 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 dla dokumentacji WPF, jak i dla innych platform, które używają języka XAML, lub podstawowych pojęć XAML włączonych przez obsługę języka XAML na poziomie System.Xaml. W tym temacie rozszerzono podstawową terminologię wprowadzona w temacie Omówienie języka XAML (WPF).

Specyfikacja języka XAML

Zdefiniowana tutaj terminologia składni XAML jest również zdefiniowana lub przywołyowana w specyfikacji języka XAML. XAML to język oparty na języku XML, który jest kontynuacją lub rozszerzeniem reguł strukturalnych XML. Niektóre terminologia jest udostępniana lub jest oparta na terminologii często używanej podczas opisywania języka XML lub modelu obiektu dokumentu 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 typowych języków, które są bezpośrednio używane przez środowisko uruchomieniowe CLR. Zamiast tego można myśleć o języku XAML jako o wspieraniu własnego systemu typów. Konkretny system analizowania XAML, który jest używany przez WPF, jest zbudowany na systemie clr i typu CLR. Typy XAML są mapowane na typy CLR w celu wystąpienia reprezentacji czasu działania podczas analizowania kodu XAML dla WPF. Z tego powodu pozostała część dyskusji o składni w tym dokumencie będzie zawierać odwołania do systemu typów CLR, mimo że równoważne dyskusje o składni w specyfikacji języka XAML tego nie robią. (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 parsera XAML).

Składowe typów i dziedziczenia klas

Właściwości i zdarzenia wyświetlane jako elementy członkowskie typu XAML są często WPF dziedziczone z typów podstawowych. Rozważmy na przykład ten przykład: <Button Background="Blue" .../> . Właściwość nie jest natychmiast zadeklarowaną właściwością klasy, jeśli chcesz przyjrzeć się definicji klasy, wynikom odbicia Background Button lub dokumentacji. Zamiast tego Background jest dziedziczona z klasy Control bazowej.

Zachowanie dziedziczenia klas elementów XAML jest znaczącym odejściem od wymuszania przez schemat WPF 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 dozwolone atrybuty są trudne do reprezentowania dokładnie i całkowicie przy użyciu typów schematu, które są zwykle używane do programowania XML, takich jak FORMAT DTD lub XSD. Innym powodem jest to, że funkcje rozszerzalności i mapowania typów języka XAML wykluczają kompletność każdej stałej reprezentacji dozwolonych typów i elementów członkowskich.

Składnia elementu obiektu

Składnia elementu obiektu to składnia znaczników XAML, która intuiuje klasę lub strukturę CLR przez zadeklarowanie elementu XML. Ta składnia przypomina składnię elementów innych języków znaczników, takich jak HTML. Składnia elementu obiektu rozpoczyna się od lewego nawiasu kątowego (), po którym natychmiast następuje nazwa typu klasy lub struktury, która < jest dawana. Po nazwie typu może być co najmniej zero spacji, a zero lub więcej atrybutów może być zadeklarowanych w elemencie obiektu, z co najmniej jedną spacją oddzielającą każdą parę atrybutu name="value". Na koniec musi być spełnione jedno z następujących:

  • Element i tag muszą być zamknięte ukośnikiem (/), po którym następuje prawy nawias kątowy (>).

  • Tag otwierający musi być uzupełniony prawym nawiasem kątowym (>). Inne elementy obiektu, elementy właściwości lub tekst wewnętrzny mogą być zgodne z tagiem otwierającym. Dokładnie to, jaka zawartość może być zawarta w tym miejscu, jest zwykle ograniczona przez model obiektów elementu. Równoważny tag zamykający elementu obiektu musi również istnieć we właściwym zagnieżdżania i równoważyć z innymi parami tagów otwierających i zamykających.

Język XAML zaimplementowany przez platformę .NET zawiera zestaw reguł, które mapuje elementy obiektu na typy, atrybuty na właściwości lub zdarzenia oraz przestrzenie nazw XAML na przestrzenie nazw CLR oraz zestaw. W przypadku platform WPF i .NET elementy obiektu XAML są mapowane na typy .NET zgodnie z definicją w zestawach, do których się odwoływuje, a atrybuty są mapowane na elementy członkowskie tych typów. Odwołując się do typu CLR w języku XAML, masz również dostęp do dziedziczonych elementów członkowskich tego typu.

Na przykład poniższy przykład to składnia elementu obiektu, która instancji nowego wystąpienia klasy, a także określa atrybut i wartość Button Name 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 obiekcie zostanie użyty do ustawienia właściwości TextBox 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 modelu zawartości lub drzewa elementów. Na przykład klasę należy zwykle umieścić tylko jako klasę podrzędną MenuItem MenuBase klasy pochodnej, takiej jak Menu . Modele zawartości dla określonych elementów są dokumentowane jako część uwag na stronach klas dla kontrolek i innych klas, które mogą WPF być używane jako elementy XAML.

Właściwości elementów obiektu

Właściwości w języku XAML są ustawiane przy użyciu różnych możliwych składni. Składnia, której można użyć dla określonej właściwości, będzie się różnić w zależności od właściwości systemu typów bazowych ustawianych właściwości.

Ustawiając wartości właściwości, można dodawać cechy lub charakterystyki do obiektów istniejących w grafie obiektów czasu uruchamiania. Początkowy stan utworzonego obiektu z elementu obiektu jest oparty na zachowaniu konstruktora bez parametrów. Zazwyczaj aplikacja 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ść właściwości przez zadeklarowanie atrybutu w istniejącym elemencie obiektu. Nazwa atrybutu musi odpowiadać nazwie elementu członkowskiego CLR właściwości klasy, która stanowi kopię zapasową odpowiedniego elementu obiektu. Po nazwie atrybutu następuje operator przypisania (=). Wartość atrybutu musi być ciągiem ujętym w cudzysłowy.

Uwaga

Możesz użyć cudzysłowów naprzemiennych, aby umieścić znak cudzysłowu literału w obrębie atrybutu. Na przykład można użyć cudzysłowów pojedynczych jako środków do zadeklarowania ciągu zawierającego znak podwójnego cudzysłowu. Bez względu na to, czy używasz cudzysłowu pojedynczego, czy podwójnego, należy użyć pasującej pary do otwierania i zamykania ciągu wartości atrybutu. Dostępne są również sekwencje ucieczki lub inne techniki do pracy z ograniczeniami znaków narzuconym przez określoną składnię XAML. Zobacz Jednostki znaków XML i XAML.

Aby można było ustawić za pomocą składni atrybutów, właściwość musi być publiczna i musi być zapisywalna. Wartość właściwości w systemie typów kopii zapasowej musi być typem wartości lub typem referencyjnym, który może być wystąpieniami lub przywoływami procesora XAML podczas uzyskiwania dostępu do odpowiedniego typu kopii zapasowej.

W przypadku zdarzeń WPF XAML zdarzenie, które jest przywołyowane jako nazwa atrybutu, musi być publiczne i mieć publicznego delegata.

Właściwość lub zdarzenie musi być składową klasy lub struktury, która jest owana przez zawierający element obiektu.

Przetwarzanie wartości atrybutów

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

Wartość atrybutu jest wypełniana przy użyciu jednej z następujących kolejności przetwarzania:

  1. Jeśli procesor XAML napotka nawias klamrowy lub element obiektu, który pochodzi od , to odwołanie do rozszerzenia znaczników jest oceniane jako pierwsze, a nie przetwarza wartość jako ciąg, a obiekt zwracany przez rozszerzenie znaczników jest używany jako MarkupExtension wartość. W wielu przypadkach obiekt zwracany przez rozszerzenie znaczników będzie odwołaniem do istniejącego obiektu lub wyrażeniem, które nie będzie oceniać do czasu uruchomienia i nie jest nowo utworzonym obiektem wystąpienia.

  2. Jeśli właściwość jest zadeklarowana z atrybutem lub typ wartości tej właściwości jest zadeklarowany z atrybutem , wartość ciągu atrybutu jest przesłana do konwertera typu jako dane wejściowe konwersji, a konwerter zwróci nowe wystąpienie TypeConverter TypeConverter obiektu.

  3. Jeśli nie ma wartości , podejmowana jest próba bezpośredniej TypeConverter konwersji na typ właściwości. Ten końcowy poziom jest bezpośrednią konwersją na wartość natywną parsera między typami pierwotnymi języka XAML lub sprawdzeniem nazw nazwanych stałych w wyliczeniu (następnie parser uzyskuje dostęp do pasujących wartości).

Wartości atrybutów wyliczenia

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

W przypadku wartości wyliczenia nonflag zachowaniem natywnym jest przetwarzanie ciągu wartości atrybutu i rozwiązywanie go do jednej z wartości wyliczenia. Wyliczenie nie jest określone w formacie Enumeration. Wartość, tak jak w kodzie. Zamiast tego należy określić tylko wartość, a wyliczenie jest wywnioskowane przez typ ustawianej właściwości. Jeśli określisz atrybut w wyliczeniu. Formularz wartości nie zostanie poprawnie rozpoznany.

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

<!--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 można ustawić 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 flagą, aby zmodyfikować przykład podany w uwagi dla Glyphs klasy; StyleSimulations = "BoldSimulation" może stać się 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ść jest szczególnym przypadekem, ponieważ ModifierKeys wyliczenie obsługuje własny konwerter typów. Konwerter typów dla 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 Windows Microsoft, na przykład "Ctrl+Alt".

Odwołania do właściwości i nazwy członka zdarzenia

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

Można też odwoływać się do dołączonej właściwości lub dołączonego zdarzenia, niezależnie od zawierającego elementu obiektu. (Dołączone właściwości zostały omówione w kolejnej 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. nazwa zdarzenia częściowo kwalifikowana; Ta składnia obsługuje dołączanie programów obsługi dla trasowane zdarzeń, gdzie program obsługi jest przeznaczony do obsługi routingu zdarzeń z elementów nadrzędnych, ale element nadrzędny nie ma również tego zdarzenia w swojej tabeli elementów członkowskich. Ta składnia przypomina składnię dołączonego zdarzenia, ale zdarzenie w tym miejscu nie jest prawdziwym zdarzeniem dołączonym. Zamiast tego odwołujesz się do zdarzenia z kwalifikowaną nazwą. Aby uzyskać więcej informacji, zobacz Routed Events Overview (Przegląd zdarzeń tras).

W niektórych scenariuszach nazwy właściwości są czasami podane jako wartość atrybutu, a nie jako nazwa atrybutu. Ta 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 często spotykany 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 Styleing and Templating (Style i szablonów).

Innym zastosowaniem nazw właściwości jest to, gdy wartość atrybutu opisuje relację właściwość-właściwość. Ta funkcja jest używana do powiązania danych i obiektów docelowych storyboard oraz jest włączana przez klasę PropertyPath i konwerter typów. Aby uzyskać bardziej szczegółowy opis semantyki wyszukiwania, zobacz PropertyPath XAML Syntax (Składnia xaml PropertyPath).

Składnia elementu właściwości

Składnia elementu właściwości to składnia, która nieco odbiega od podstawowych reguł składni XML dla elementów. W języku XML wartość atrybutu jest de facto ciągiem, przy czym jedyną możliwą odmianą jest format kodowania ciągów, który jest używany. W języku XAML można przypisać inne elementy obiektu jako wartość właściwości. Ta możliwość jest włączana przez składnię elementu właściwości. Zamiast właściwości określonej jako atrybut w tagu elementu, właściwość jest określana przy użyciu otwierającego tagu elementu w elemencie elementTypeName. propertyName form, wartość właściwości jest określona w elemencie , a następnie element właściwości jest zamykany.

W szczególności składnia rozpoczyna się od lewego nawiasu kątowego ( <), followed immediately by the type name of the class or structure that the property element syntax is contained within. This is followed immediately by a single dot (.), then by the name of a property, then by a right angle bracket (> ). Podobnie jak w przypadku składni atrybutów, ta właściwość musi istnieć w obrębie zadeklarowanych publicznych elementów członkowskich określonego typu. Wartość, która ma zostać przypisana do właściwości, jest zawarta w elemencie właściwości. Zazwyczaj wartość jest podana jako co najmniej jeden element obiektu, ponieważ określanie obiektów jako wartości jest scenariuszem, w którym ma zostać rozwiązana składnia elementu właściwości. Na koniec równoważny tag zamykający określający ten sam elementTypeName. Należy podać kombinację propertyName we właściwym zagnieżdżeniu i równoważyć z innymi tagami elementów.

Na przykład poniżej przedstawiono składnię elementu właściwości ContextMenu dla właściwości elementu 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ść w elemencie 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 , lub wyliczeniem, w którym określono String nazwę. Te dwa zastosowania są nieco nietypowe, ponieważ w każdym z tych przypadków można również użyć prostszej składni atrybutów. Jeden ze scenariuszy wypełniania elementu właściwości ciągiem jest dla właściwości, które nie są właściwością zawartości XAML, ale są nadal używane do reprezentacji tekstu interfejsu użytkownika, a konkretne elementy odstępu, takie jak linefeeds, muszą pojawić się w tym tekście interfejsu użytkownika. Składnia atrybutów nie może zachować linefeeds, ale składnia elementu właściwości może, tak długo, jak znaczące zachowywanie białych spacji jest aktywne (aby uzyskać szczegółowe informacje, zobacz Przetwarzanie białych spacji w XAML). Innym scenariuszem jest to, że dyrektywę x:Uid można zastosować do elementu właściwości i w związku z tym oznaczyć wartość w elemencie jako wartość, która powinna być zlokalizowane w wyjściowym pliku BAML WPF lub za pomocą innych technik.

Element właściwości nie jest reprezentowany w drzewie logicznym WPF. Element właściwości to po prostu określonej składni do ustawiania właściwości i nie jest elementem, który ma wystąpienie lub obiekt kopię zapasową. (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, te dwie składnie zazwyczaj mają taki sam wynik, chociaż subtelności, takie jak obsługa odstępów, mogą się nieznacznie różnić między składniami.

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 .NET jest oparta na kodzie zarządzanym i clr i identyfikuje typy kolekcji za pomocą jednej z następujących czynności:

Jeśli typ właściwości jest kolekcją, wywnioskować 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 obliczany do obiektu podczas ładowania i dodawany do kolekcji przez wywołanie Add metody niejawnej kolekcji. Na przykład właściwość przyjmuje wyspecjalizowany typ Triggers Style kolekcji TriggerCollection , który implementuje obiekt IList . Nie jest konieczne, aby utworzyć wystąpienia elementu TriggerCollection obiektu w znacznikach. Zamiast tego należy określić co najmniej jeden element jako elementy w elemencie właściwości, gdzie (lub klasa pochodna) jest typem oczekiwanym jako typ elementu dla silnie typifikatora i Trigger Style.Triggers Trigger 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, co omówiono w następnej sekcji tego tematu.

Niejawny element kolekcji tworzy element członkowski w reprezentacji drzewa logicznego, mimo że nie jest wyświetlany w znacznikach jako element. Zazwyczaj konstruktor typu nadrzędnego wykonuje tworzenie wystąpienia kolekcji, która jest jedną z jej 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 ) nie są obsługiwane w przypadku IDictionary<TKey,TValue> wykrywania kolekcji. Można jednak użyć klasy jako klasy bazowej, ponieważ implementuje bezpośrednio lub jako klasę List<T> IList bazową, ponieważ Dictionary<TKey,TValue> implementuje IDictionary bezpośrednio.

Na stronach odwołania .NET dla typów kolekcji ta składnia z celowym pominięciem elementu obiektu dla kolekcji jest czasami zapisywana w sekcjach składni JĘZYKA XAML jako niejawna składnia 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 tak naprawdę elementem, który jest jednym lub w obu następujących przypadkach: element członkowski niejawnej właściwości kolekcji jego elementu nadrzędnego lub element określający wartość właściwości zawartości XAML dla elementu nadrzędnego (właściwości zawartości XAML zostaną omówione w następnej sekcji). Innymi słowy, relacja elementów nadrzędnych i elementów nadrzędnych na stronie znaczników jest tak naprawdę pojedynczym obiektem w katalogu głównym, a każdy element obiektu pod katalogiem głównym jest pojedynczym wystąpieniem, które udostępnia wartość właściwości elementu nadrzędnego, lub jednym z elementów w kolekcji, który jest również wartością właściwości typu kolekcja elementu nadrzędnego. Ta koncepcja pojedynczego elementu głównego jest wspólna dla kodu XML i często jest wzmacniana w zachowaniu interfejsów API, które ładują kod XAML, taki jak Load .

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

<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 jest możliwe jawne zadeklarowanie kolekcji. Na przykład próba jawnego zadeklarowania w pokazanym wcześniej TriggerCollection Triggers przykładzie nie powiedzie się. Jawne deklarowanie kolekcji wymaga, aby klasa kolekcji obsługiła konstruktor bez parametrów i nie ma konstruktora bez TriggerCollection parametrów.

Właściwości zawartości XAML

Składnia zawartości XAML to składnia, która jest włączona tylko dla klas, które określają element ContentPropertyAttribute jako część deklaracji klasy. Element ContentPropertyAttribute odwołuje 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, które znajdują się między otwierającymi i zamykającymi tagami elementu obiektu, zostaną przypisane do wartości właściwości zawartości XAML dla tego obiektu. Możesz określić jawne elementy właściwości dla właściwości content, ale to użycie nie jest ogólnie widoczne w sekcjach składni JĘZYKA XAML w odwołaniach .NET. Technika jawna/szczegółowa ma sporadyczną wartość dla przejrzystości na znaczników lub jako kwestia stylu nacjonalności, ale zwykle celem właściwości zawartości jest usprawnienie na znaczników, dzięki czemu 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ść" zgodnie z rygorystyczną definicją języka XAML; Są one przetwarzane wcześniej w kolejności przetwarzania przez parser 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 elemencie obiektu. Dotyczy to tego, 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ż gdyby ta składnia była jawna przy użyciu składni elementu właściwości dla właściwości content, właściwość content zostanie ustawiona dwukrotnie:

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

Podobnie niedozwolonym przykładem jest sytuacja, gdy właściwość content jest kolekcją, a elementy podrzędne są przeplatone 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 można było zaakceptować więcej niż jeden element obiektu jako zawartość, typ właściwości content musi być w szczególności typem kolekcji. Podobnie jak w przypadku typów kolekcji składnia elementów właściwości, 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ą, niejawny typ kolekcji 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 model zawartości w znacznikach może teraz mieć przypisany więcej niż jeden element podrzędny jako zawartość. Poniżej przedstawiono składnię zawartości dla Panel klasy pochodnej. Wszystkie Panel klasy pochodne ustanawiają właściwość zawartości XAML na wartość , co wymaga wartości typu Children 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 zauważyć, że w znacznikach nie jest wymagany ani element właściwości ani element dla Children UIElementCollection elementu . Jest to funkcja projektowania języka XAML, dzięki czemu rekursywnie zawarte elementy, które definiują obiekt , są bardziej intuicyjnie reprezentowane jako drzewo zagnieżdżonych elementów z bezpośrednimi relacjami elementów nadrzędny-podrzędny bez interweniowania tagów elementów właściwości ani obiektów Interfejs użytkownika kolekcji. W rzeczywistości nie UIElementCollection można jawnie określić znaczników jako elementu obiektu, zgodnie z projektem. Ponieważ jej jedynym przeznaczeniem jest niejawna kolekcja, nie uwidacznia publicznego konstruktora bez parametrów i w związku z tym nie można utworzyć wystąpienia UIElementCollection jako elementu obiektu.

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

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

Jako pierwszy bezpośredni znacznik w elemencie obiektu może być element obiektu podrzędnego. Następnie możesz wprowadzić elementy właściwości. Można też określić co najmniej jeden element właściwości, następnie zawartość, a następnie więcej elementów właściwości. Jednak gdy element właściwości następuje po zawartości, nie można wprowadzać dalszej zawartości, można dodawać tylko elementy właściwości.

To wymaganie dotyczące kolejności elementów zawartości/właściwości nie ma zastosowania do tekstu wewnętrznego używanego jako zawartość. Jednak nadal dobrym stylem na znaczników jest zachowanie ciągłego tekstu wewnętrznego, ponieważ znaczne białe znaki będą trudne do wykrycia wizualnie w znacznikach, jeśli elementy właściwości są przeplatone tekstem wewnętrznym.

Przestrzeń nazw XAML

Żaden z powyższych przykładów składni nie określał przestrzeni nazw XAML innej niż domyślna przestrzeń nazw XAML. W typowych WPF aplikacjach domyślna przestrzeń nazw XAML jest określana jako przestrzeń WPF nazw. Można 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 zamapowany na odpowiednią przestrzeń nazw CLR. Na przykład to składnia elementu obiektu służąca do wystąpienia wystąpienia klasy, w której przestrzeń nazw CLR zawierająca klasę (i prawdopodobnie informacje o zestawie zewnętrznym, który zawiera typy zapasowe) została wcześniej zamapowana na <custom:Example/> Example custom prefiks.

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

Rozszerzenia struktury znaczników

XAML definiuje jednostkę programowania rozszerzenia znaczników, która umożliwia ucieczkę od normalnej obsługi procesora XAML wartości atrybutów ciągu lub elementów obiektu i odraża przetwarzanie do klasy zapasowej. Znak, który identyfikuje rozszerzenie znaczników dla procesora XAML w przypadku używania składni atrybutów, 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 zachowanie określonego rozszerzenia, gdzie odwołanie może pominąć podciąg "Extension", jeśli ten podciąg jest częścią nazwy klasy true. Później może pojawić się jedna spacja, a następnie każdy kolejny znak będzie używany jako dane wejściowe przez implementację rozszerzenia aż do momentu napotkania zamykającego nawiasu klamrowego.

Implementacja języka XAML na platformie .NET używa klasy abstrakcyjnej jako podstawy dla wszystkich rozszerzeń znaczników obsługiwanych przez, a także innych platform MarkupExtension WPF lub technologii. Rozszerzenia znaczników, które w szczególności implementują, są często przeznaczone do zapewnienia możliwości odwołania się do innych istniejących obiektów lub do odroczonych odwołań do obiektów, które będą oceniane w WPF czasie działania. Na przykład proste powiązanie danych WPF jest realizowane przez określenie rozszerzenia znaczników w miejsce wartości, która normalnie byłaby dzielona na określoną {Binding} właściwość. Wiele rozszerzeń znaczników WPF umożliwia składnię atrybutów dla właściwości, w przypadku których składnia atrybutów nie byłaby w przeciwnym razie możliwa. Na przykład obiekt Style jest stosunkowo złożonym typem zawierającym zagnieżdżony szereg obiektów i właściwości. Style w WPF są zwykle definiowane jako zasób w , a następnie przywoływują się za pośrednictwem jednego z dwóch rozszerzeń ResourceDictionary znaczników WPF, które żądają zasobu. Rozszerzenie znaczników odraża ocenę wartości właściwości do wyszukiwania zasobów i umożliwia podanie wartości właściwości, biorąc typ , w składni atrybutu, jak w Style Style poniższym przykładzie:

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

W tym StaticResource miejscu identyfikuje StaticResourceExtension klasę dostarczającą implementację rozszerzenia znaczników. Następny ciąg jest używany jako dane wejściowe dla konstruktora nie domyślnego, gdzie parametr w postaci żądanej deklaruje ciąg MyStyle StaticResourceExtension ResourceKey rozszerzenia. MyStyle Oczekuje się, że będzie to wartość x:Key Style zdefiniowanej jako zasób. Rozszerzenie znaczników StaticResource żąda, aby zasób był używany do zapewnienia wartości właściwości za pośrednictwem statycznej logiki wyszukiwania zasobów Style w czasie ładowania.

Aby uzyskać więcej informacji na temat rozszerzeń znaczników, zobacz Rozszerzenia znaczników i WPF XAML. Aby uzyskać odwołanie do rozszerzeń znaczników i innych funkcji programowania XAML włączonych w ogólnej implementacji języka XAML na platformie .NET, zobacz Przestrzeń nazw XAML (x:) Funkcje językowe. Aby uzyskać informacje na temat rozszerzeń znaczników specyficznych dla WPF,zobacz Rozszerzenia WPF XAML .

Właściwości dołączone

Właściwości dołączone to pojęcie programistyczne wprowadzone w języku XAML, w którym właściwości mogą być własnością określonego typu i przez nie definiowane, ale ustawiane jako atrybuty lub elementy właściwości w dowolnym elemencie. Podstawowym scenariuszem, w którym są dołączone właściwości, jest umożliwienie elementom podrzędnym w strukturze znaczników zgłaszania informacji do elementu nadrzędnego bez konieczności obszernego modelu obiektów udostępnionych 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 nadrzę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 Attached Properties Overview (Omówienie dołączonych właściwości).

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

  • Można użyć typuNazwa. Kombinacja propertyName nawet podczas ustawiania dołączonej właściwości za pomocą składni atrybutu. Dołączone właściwości to jedyny przypadek, w którym kwalifikowanie nazwy właściwości jest wymagane w składni atrybutów.

  • 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 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ą definiującą właściwość dołączona, a nie zawierający element obiektu.

Zdarzenia dołączone

Zdarzenia dołączone to kolejna koncepcja programowania wprowadzona w języku XAML, w której zdarzenia mogą być definiowane przez określony typ, ale procedury obsługi mogą być dołączane do dowolnego elementu obiektu. W implementacji WOF często typ, który definiuje dołączone zdarzenie, jest typem statycznym definiującym usługę, a czasami te dołączone zdarzenia są uwidocznione przez alias zdarzenia trasowane w typach, które uwidoczniają usługę. Procedury obsługi dla dołączonych zdarzeń są określane za pomocą składni atrybutów. Podobnie jak w przypadku dołączonych zdarzeń, składnia atrybutu jest rozwinięta dla dołączonych zdarzeń, aby zezwolić na typName. użycie eventName, gdzie typeName jest klasą, która zapewnia dostęp do programu obsługi zdarzeń i dla dołączonej infrastruktury zdarzeń, a Add Remove eventName jest nazwą zdarzenia.

Anatomia elementu głównego XAML

W poniższej tabeli przedstawiono typowy element główny XAML z podziałem, pokazujący określone atrybuty elementu głównego:

<Page Otwieranie elementu obiektu elementu głównego
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" Domyślna przestrzeń nazw WPF XAML ()
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 znacznik z dowolnym kodem zdefiniowanym dla klasy częściowej
> Koniec elementu obiektu dla katalogu głównego. Obiekt nie jest jeszcze zamknięty, ponieważ element zawiera elementy podrzędne

Opcjonalne i nierecomedywne użycie xaml

W poniższych sekcjach opisano użycie języka XAML, które jest technicznie obsługiwane przez procesory XAML, ale które wywołują szczegółowość lub inne problemy z wyglądem, które zakłócają czytelność plików XAML podczas tworzenia aplikacji zawierających źródła XAML.

Użycie opcjonalnego elementu właściwości

Opcjonalne użycie elementów właściwości obejmuje jawne zapisywanie właściwości zawartości elementu, które procesor XAML uznaje za niejawne. Na przykład podczas deklarowania zawartości obiektu można jawnie zadeklarować kolekcję elementu jako tag elementu właściwości i umieścić je w obiekcie , zamiast korzystać z niejawnego zachowania procesora XAML, zgodnie z którym wszystkie elementy podrzędne obiektu muszą być elementami i są umieszczane w Menu Items Menu <Menu.Items> MenuItem <Menu.Items> Menu MenuItem Items kolekcji. Czasami opcjonalne zastosowania mogą pomóc w wizualnej wyjaśnieniu struktury obiektu, jak pojmuje się w znacznikach. Czasami jawne użycie elementu właściwości może uniknąć na znaczników, które są technicznie funkcjonalne, ale wizualnie mylące, na przykład zagnieżdżone rozszerzenia znaczników w wartości atrybutu.

Full typeName.memberName Qualified Attributes

TypNazwa. Formularz memberName atrybutu w rzeczywistości działa bardziej uniwersalnie niż tylko przypadek zdarzenia trasowane. Jednak w innych sytuacjach ta forma jest zbyt zbędna i należy jej unikać, jeśli tylko ze względu na styl i czytelność narzutu. W poniższym przykładzie każde z trzech odwołań do Background atrybutu 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 wyszukiwania dla tej właściwości na pomyślnie ( został odziedziczony z Formant) i jest klasą elementu obiektu Button Background lub klasy Button bazowej. Control.Background działa, Control ponieważ klasa faktycznie definiuje Background klasę i Control jest Button klasą bazową.

Jednak w przypadku następującego typuNazwa: Przykład formularza memberName nie działa i w związku z tym jest wyświetlany jako komentarz:

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

Label jest inną klasą pochodną klasy , a jeśli określono w elemencie obiektu, to Control Label.Background użycie Label działałoby. Jednak ponieważ nie jest klasą ani klasą bazową klasy , określonym zachowaniem procesora XAML jest przetwarzanie Label Button jako Label.Background dołączona właściwość. Label.Background nie jest dostępną właściwością dołączona, a to użycie kończy się niepowodzeniem.

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

W analogiczny sposób, jak typeName. Formularz memberName działa w przypadku składni atrybutów, baseTypeName. Składnia memberName działa w przypadku 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>

Tutaj element właściwości został podany tak, jakby Control.Background element właściwości znajdował się w elemencie Button .

Ale podobnie jak typeName. Formularz memberName dla atrybutów, baseTypeName. Parametr memberName ma zły styl w znacznikach i należy go unikać.

Zobacz też