XAML-syntax i detalj

Det här avsnittet definierar de termer som används för att beskriva elementen i XAML-syntaxen. Dessa termer används ofta under resten av den här dokumentationen, både för WPF-dokumentation specifikt och för andra ramverk som använder XAML eller de grundläggande XAML-begreppen som aktiveras av XAML-språkstöd på System.Xaml-nivå. Det här avsnittet bygger vidare på den grundläggande terminologi som introducerades i ämnet XAML i WPF.

XAML-språkspecifikationen

Den XAML-syntaxterminologi som definieras här definieras eller refereras också i XAML-språkspecifikationen. XAML är ett språk som baseras på XML och följer eller utökar xml-strukturregler. En del av terminologin delas från eller baseras på den terminologi som ofta används när du beskriver XML-språket eller XML-dokumentobjektmodellen.

Mer information om XAML-språkspecifikationen finns i Ladda ned [MS-XAML] från Microsoft Download Center.

XAML och CLR

XAML är ett markeringsspråk. Common Language Runtime (CLR), som namnet antyder, möjliggör exekvering vid körning. XAML är inte ett av de standard språk som används direkt av CLR-körtiden. I stället kan du tänka på XAML som stöd för sitt eget typsystem. Det specifika XAML-parsningssystemet som används av WPF bygger på CLR och CLR-typsystemet. XAML-typer mappas till CLR-typer för att instansiera en körningstidsrepresentation när XAML för WPF parsas. Därför innehåller resten av diskussionen om syntax i det här dokumentet referenser till CLR-typsystemet, även om motsvarande syntaxdiskussioner i XAML-språkspecifikationen inte gör det. (Enligt XAML-språkspecifikationsnivån kan XAML-typer mappas till andra typsystem, vilket inte behöver vara CLR, men det skulle kräva att en annan XAML-parser skapas och används.)

Medlemmar i typer och klassarv

Egenskaper och händelser såsom de visas som XAML-medlemmar av en WPF-typ är ofta ärvda från bastyper. Tänk till exempel på det här exemplet: <Button Background="Blue" .../>. Egenskapen Background är inte en omedelbart deklarerad egenskap för Button klassen, om du skulle titta på klassdefinitionen, reflektionsresultatet eller dokumentationen. I stället ärvs Background från basklassen Control.

Klassarvbeteendet för WPF XAML-element är ett betydande avsteg från en schemagenomtvingande tolkning av XML-kod. Klassarv kan bli komplext, särskilt när mellanliggande basklasser är abstrakta eller när gränssnitt ingår. Det här är en anledning till att uppsättningen XAML-element och deras tillåtna attribut är svåra att representera korrekt och fullständigt med hjälp av de schematyper som vanligtvis används för XML-programmering, till exempel DTD- eller XSD-format. En annan orsak är att utöknings- och typmappningsfunktioner i själva XAML-språket utesluter fullständighet av alla fasta representationer av de tillåtna typerna och medlemmarna.

Syntax för objektelement

Objektelementsyntax är XAML-markeringssyntaxen som instansierar en CLR-klass eller -struktur genom att deklarera ett XML-element. Denna syntax liknar elementsyntaxen för andra uppmärkningsspråk, till exempel HTML. Syntaxen för objektelement börjar med en vänster vinkelparentes (<), följt omedelbart av typnamnet för klassen eller strukturen som instansieras. Noll eller fler blanksteg kan följa typnamnet, och noll eller fler attribut kan också deklareras på objektelementet, med ett eller flera blanksteg som avgränsar varje attributnamn="värde"-par. Slutligen måste något av följande vara sant:

• Elementet och taggen måste stängas med ett snedstreck (/) följt omedelbart av en högervinklig hakparentes (>).

• Öppningstaggen måste fyllas i med en höger vinkelparentes (>). Andra objektelement, egenskapselement eller inre text kan följa den inledande taggen. Exakt vilket innehåll som kan finnas här begränsas vanligtvis av elementets objektmodell. Motsvarande avslutande tagg för objektelementet måste också finnas, i korrekt kapsling och balans med andra inledande och avslutande taggpar.

XAML som implementeras av .NET har en uppsättning regler som mappar objektelement till typer, attribut till egenskaper eller händelser och XAML-namnområden till CLR-namnområden plus sammansättning. För WPF och .NET mappas XAML-objektelement till .NET-typer enligt definitionen i refererade sammansättningar och attributen mappas till medlemmar av dessa typer. När du refererar till en CLR-typ i XAML har du också åtkomst till de ärvda medlemmarna av den typen.

Följande exempel är till exempel objektelementsyntax som instansierar en ny instans av Button klassen och även anger ett Name attribut och ett värde för det attributet:

<Button Name="CheckoutButton"/>

Följande exempel är objektelementsyntax som även innehåller syntax för XAML-innehållsegenskap. Den inre texten som finns här används för att ange XAML-innehållsegenskapen TextBox, Text.

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

Innehållsmodeller

En klass kan ha stöd för en användning som ett XAML-objektelement när det gäller syntaxen, men elementet fungerar bara korrekt i ett program eller en sida när det placeras i en förväntad position för en övergripande innehållsmodell eller ett elementträd. Till exempel bör en MenuItem vanligtvis bara placeras som barn till en klass härledd från MenuBase, till exempel Menu. Innehållsmodeller för specifika element dokumenteras som en del av kommentarerna på klasssidorna för kontroller och andra WPF-klasser som kan användas som XAML-element.

Egenskaper för objektelement

Egenskaper i XAML anges av en mängd olika möjliga syntaxer. Vilken syntax som kan användas för en viss egenskap varierar beroende på den underliggande typen av systemegenskaper för den egenskap som du ställer in.

Genom att ange värden för egenskaper lägger du till funktioner eller egenskaper i objekt som de finns i objektdiagrammet för körningstid. Det ursprungliga tillståndet för det skapade objektet från ett objektelement baseras på det parameterlösa konstruktorns beteende. Vanligtvis använder programmet något annat än en helt standardinstans av ett visst objekt.

Attributsyntax (egenskaper)

Attributsyntax är XAML-markeringssyntaxen som anger ett värde för en egenskap genom att deklarera ett attribut för ett befintligt objektelement. Attributnamnet måste matcha CLR-medlemsnamnet för egenskapen för den klass som stöder det relevanta objektelementet. Attributnamnet följs av en tilldelningsoperator (=). Attributvärdet måste vara en sträng inom citattecken.

För att kunna ställas in via attributsyntax måste en egenskap vara offentlig och vara skrivbar. Värdet för egenskapen i backningstypsystemet måste vara en värdetyp, eller vara en referenstyp som kan instansieras eller refereras av en XAML-processor vid åtkomst till relevant backningstyp.

För WPF XAML-händelser måste händelsen som refereras som attributnamn vara offentlig och ha ett offentligt ombud.

Egenskapen eller händelsen måste vara medlem i den klass eller struktur som instansieras av det innehållande objektelementet.

Bearbetning av attributvärden

Strängvärdet inom de inledande och avslutande citattecknen bearbetas av en XAML-processor. För egenskaper bestäms standardbearbetningsbeteendet av typen för den underliggande CLR-egenskapen.

Attributvärdet fylls i av något av följande, med hjälp av den här bearbetningsordningen:

1. Om XAML-processorn stöter på en klammerparentes, eller ett objektelement som härleds från MarkupExtension, utvärderas det refererade markeringstillägget först i stället för att bearbeta värdet som en sträng, och objektet som returneras av markeringstillägget används som värde. I många fall är objektet som returneras av ett markeringstillägg en referens till ett befintligt objekt, eller ett uttryck som skjuter upp utvärderingen till körningstid och inte är ett nyligen instansierat objekt.

2. Om egenskapen deklareras med en tilldelad TypeConverter, eller om värdetypen för den egenskapen deklareras med en attribut TypeConverter, skickas strängvärdet för attributet till typkonverteraren som konverteringsindata, och konverteraren returnerar en ny objektinstans.

3. Om det inte finns någon TypeConvertergörs ett försök med en direkt konvertering till egenskapstypen. Den här sista nivån är en direkt konvertering till parser-native-värdet mellan primitiva XAML-språktyper eller en kontroll av namnen på namngivna konstanter i en uppräkning (parsern kommer sedan åt matchande värden).

Uppräkningsattributvärden

Uppräkningar i XAML bearbetas i sig av XAML-parsare, och medlemmarna i en uppräkning bör anges genom att ange strängnamnet för en av uppräkningskonstanternas namngivna konstanter.

För ickeflag-uppräkningsvärden är det inbyggda beteendet att bearbeta strängen för ett attributvärde och matcha den till ett av uppräkningsvärdena. Du anger inte uppräkningen i formatet Uppräkning. Värde, som du gör i kod. I stället anger du bara Värde, och Uppräkning härleds av den typ av egenskap som du anger. Om du anger ett attribut i Enumeration.Value, kommer det inte att lösas korrekt.

För flagwise-uppräkningar baseras beteendet på Enum.Parse metoden. Du kan ange flera värden för en flaggvis uppräkning genom att separera varje värde med ett kommatecken. Du kan dock inte kombinera uppräkningsvärden som inte är flaggande. Du kan till exempel inte använda kommasyntaxen för att försöka skapa en Trigger som fungerar på flera villkor av en icke-flagga uppräkningstyp:

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

Flagwise-uppräkningar som stöder attribut som kan anges i XAML är sällsynta i WPF. En sådan uppräkning är dock StyleSimulations. Du kan till exempel använda syntaxen för kommaavgränsade flagwise-attribut för att ändra exemplet som anges i klassen Kommentarer Glyphs , StyleSimulations = "BoldSimulation" kan bli StyleSimulations = "BoldSimulation,ItalicSimulation". KeyBinding.Modifiers är en annan egenskap där mer än ett uppräkningsvärde kan anges. Den här egenskapen råkar dock vara ett specialfall eftersom ModifierKeys uppräkningen stöder en egen typkonverterare. Typkonverteraren för modifierare använder ett plustecken (+) som avgränsare i stället för kommatecken (,). Den här konverteringen stöder den mer traditionella syntaxen för att representera nyckelkombinationer i Microsoft Windows-programmering, till exempel "Ctrl+Alt".

Egenskaper och namnreferenser för händelsemedlem

När du anger ett attribut kan du referera till alla egenskaper eller händelser som finns som en medlem av den CLR-typ som du instansierade för det innehållande objektelementet.

Eller så kan du referera till en bifogad egenskap eller bifogad händelse, oberoende av det innehållande objektelementet. (Bifogade egenskaper beskrivs i ett kommande avsnitt.)

Du kan också identifiera händelser från alla objekt som är tillgängliga via standardnamnområdet med hjälp av ett typeName.händelse delvis kvalificerat namn; denna syntax stöder att koppla hanterare för dirigerade händelser där hanteraren är avsedd att hantera händelsedirigering från underordnade element, men det överordnade elementet saknar den händelsen i sin medlemstabell. Den här syntaxen liknar en bifogad händelsesyntax, men händelsen här är inte en sann bifogad händelse. I stället refererar du till en händelse med ett kvalificerat namn. Mer information finns i Översikt över routade händelser.

I vissa scenarier anges egenskapsnamn ibland som värdet för ett attribut i stället för attributnamnet. Egenskapsnamnet kan även innehålla kvalificerare, till exempel egenskapen som anges i formuläret ownerType. dependencyPropertyName. Det här scenariot är vanligt när du skriver formatmallar eller mallar i XAML. Bearbetningsreglerna för egenskapsnamn som anges som ett attributvärde skiljer sig åt och styrs av typen av egenskapen som anges eller av beteendet för vissa WPF-undersystem. Mer information finns i Formatering och templating.

En annan användning för egenskapsnamn är när ett attributvärde beskriver en egenskapsrelation. Den här funktionen används för databindning och för storyboard-mål och aktiveras av PropertyPath klassen och dess typkonverterare. En mer fullständig beskrivning av uppslagssemantiken finns i PropertyPath XAML-syntax.

Syntax för egenskapselement

Syntax för egenskapselement är en syntax som avviker något från de grundläggande XML-syntaxreglerna för element. I XML är värdet för ett attribut en de facto-sträng, där den enda möjliga varianten är vilket strängkodningsformat som används. I XAML kan du tilldela andra objektelement till värdet för en egenskap. Den här funktionen aktiveras av syntaxen för egenskapselementet. I stället för att egenskapen anges som ett attribut i elementtaggen anges egenskapen med hjälp av en inledande elementtagg i elementTypeName. propertyName-formulär , värdet för egenskapen anges i och sedan stängs egenskapselementet.

Mer specifikt börjar syntaxen med en vänster vinkelparentes (<), följt omedelbart av typnamnet för klassen eller strukturen som egenskapselementsyntaxen finns i. Detta följs omedelbart av en enda punkt (.), sedan av namnet på en egenskap, sedan av en höger vinkelparentes (>). Precis som med attributsyntaxen måste den egenskapen finnas inom de deklarerade offentliga medlemmarna av den angivna typen. Värdet som ska tilldelas egenskapen finns i egenskapselementet. Vanligtvis anges värdet som ett eller flera objektelement, eftersom det scenario som egenskapselementsyntaxen är avsedd att adressera är att ange objekt som värden. Slutligen måste en motsvarande avslutande tagg som anger samma elementTypeNamepropertyName-kombination specificeras och vara i korrekt kapsling och balans med andra elementtaggar.

Till exempel är följande syntax för ett egenskapselement för ContextMenu-egenskapen i en Button.

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

Värdet i ett egenskapselement kan också anges som inre text, i fall där egenskapstypen som anges är en primitiv värdetyp, till exempel String, eller en uppräkning där ett namn anges. Dessa två användningar är något ovanliga, eftersom vart och ett av dessa fall också kan använda en enklare attributsyntax. Ett scenario för att fylla ett egenskapselement med en sträng är för egenskaper som inte är XAML-innehållsegenskapen, men som fortfarande används för representation av användargränssnittstext, och särskilda blankstegselement som radfeeds måste visas i användargränssnittstexten. Attributsyntaxen kan inte bevara linjefeeds, men syntax för egenskapselement kan, så länge betydande bevarande av tomt utrymme är aktivt (mer information finns i Bearbetning av tomt utrymme i XAML). Ett annat scenario är att x:Uid-direktivet kan tillämpas på egenskapselementet och därmed markera värdet inom som ett värde som ska lokaliseras i WPF-utdata-BAML eller med andra tekniker.

Ett egenskapselement representeras inte i det logiska WPF-trädet. Ett egenskapselement är bara en viss syntax för att ange en egenskap och är inte ett element som har en instans eller ett objekt som stöder den. (Mer information om det logiska trädkonceptet finns i Träd i WPF.)

För egenskaper där både attribut- och egenskapselementsyntax stöds har de två syntaxerna vanligtvis samma resultat, även om subtiliteter som hantering av blanksteg kan variera något mellan syntaxer.

Samlingssyntax

XAML-specifikationen kräver XAML-processorimplementeringar för att identifiera egenskaper där värdetypen är en samling. Den allmänna XAML-processorimplementeringen i .NET baseras på hanterad kod och CLR och identifierar samlingstyper via något av följande:

• Typ implementerar IList.

• Typ implementerar IDictionary.

• Typ härleds från Array (mer information om matriser i XAML finns i x:Array Markup Extension.)

Om typen av en egenskap är en samling behöver inte den härledda samlingstypen anges i markering som ett objektelement. I stället anges de element som är avsedda att bli objekten i samlingen som ett eller flera underordnade element i egenskapselementet. Varje sådan post utvärderas till ett objekt under inläsningen och läggs till i samlingen genom att anropa Add metoden för den angivna samlingen. Egenskapen Triggers för Style använder till exempel den specialiserade samlingstypen TriggerCollection, som implementerar IList. Det är inte nödvändigt att instansiera ett TriggerCollection objektelement i markeringen. I stället anger du ett eller flera Trigger objekt som element i Style.Triggers egenskapselementet, där Trigger (eller en härledd klass) är den typ som förväntas som objekttyp för den starkt inskrivna och implicita 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>

En egenskap kan vara både en samlingstyp och XAML-innehållsegenskapen för den typen och härledda typer, vilket beskrivs i nästa avsnitt i det här avsnittet.

Ett implicit samlingselement skapar en medlem i den logiska trädrepresentationen, även om det inte visas i markeringen som ett element. Konstruktorn av den överordnade typen utför vanligtvis instansiering för samlingen som är en av dess egenskaper, och den initialt tomma samlingen blir en del av objektträdet.

På .NET-referenssidorna för samlingstyper anges den här syntaxen med avsiktlig utelämnande av objektelementet för en samling ibland i XAML-syntaxavsnitten som implicit samlingssyntax.

Med undantag för rotelementet är varje objektelement i en XAML-fil som är kapslad som ett underordnat element i ett annat element egentligen ett element som är ett eller båda av följande fall: en medlem av en implicit samlingsegenskap för dess överordnade element eller ett element som anger värdet för XAML-innehållsegenskapen för det överordnade elementet (XAML-innehållsegenskaper beskrivs i ett kommande avsnitt). Med andra ord är relationen mellan parent-element och child-element på en markeringssida i själva verket ett enda objekt vid roten, och varje objekt under roten är antingen en specifik instans som ger ett värde för en egenskap hos parent-elementet, eller ett av föremålen i en samling som också utgör ett värde för en datatypegenskap hos parent-elementet. Det här enkelrotskonceptet är vanligt med XML och förstärks ofta i beteendet för API:er som läser in XAML, till exempel Load.

Följande exempel är en syntax med objektelementet för en samling (GradientStopCollection) som uttryckligen anges.

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

Observera att det inte alltid är möjligt att uttryckligen deklarera samlingen. Om du till exempel försöker deklarera TriggerCollection explicit i exemplet som visades Triggers tidigare skulle det misslyckas. För att explicit deklarera samlingen krävs att samlingsklassen måste ha stöd för en parameterlös konstruktor och TriggerCollection inte har någon parameterlös konstruktor.

Egenskaper för XAML-innehåll

XAML-innehållssyntax är en syntax som endast är aktiverad för klasser som anger ContentPropertyAttribute som en del av deras klassdeklaration. Refererar ContentPropertyAttribute till egenskapsnamnet som är innehållsegenskapen för den typen av element (inklusive härledda klasser). När de bearbetas av en XAML-processor tilldelas alla underordnade element eller inre text som finns mellan de inledande och avslutande taggarna för objektelementet värdet för XAML-innehållsegenskapen för objektet. Du kan ange explicita egenskapselement för innehållsegenskapen, men den här användningen visas vanligtvis inte i XAML-syntaxavsnitten i .NET-referensen. Den explicita/utförliga tekniken har ibland värde för tydlighet i markeringen eller som en del av markeringsstil, men vanligtvis är avsikten med en innehållsegenskap att effektivisera markeringen så att element som är intuitivt relaterade som förälder-barn kan kapslas direkt. Egenskapselementtaggar för andra egenskaper i ett element tilldelas inte som "innehåll" enligt en strikt XAML-språkdefinition. de bearbetas tidigare i XAML-parsarens bearbetningsordning och anses inte vara "innehåll".

XAML-innehållsegenskapsvärden måste vara sammanhängande

Värdet för en XAML-innehållsegenskap måste anges antingen helt före eller helt efter andra egenskapselement i objektelementet. Detta gäller om värdet för en XAML-innehållsegenskap anges som en sträng eller som ett eller flera objekt. Följande markering parsar till exempel inte:

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

Detta är ogiltigt eftersom om den här syntaxen har gjorts explicit med hjälp av egenskapselementsyntax för innehållsegenskapen, så skulle innehållsegenskapen anges två gånger:

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

Ett liknande olagligt exempel är om innehållsegenskapen är en samling och underordnade element är blandade med egenskapselement.

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

Innehållsegenskaper och samlingssyntax kombinerad

För att kunna acceptera mer än ett objektelement som innehåll måste innehållsegenskapens typ specifikt vara en samlingstyp. På samma sätt som egenskapselementsyntax för samlingstyper måste en XAML-processor identifiera typer som är samlingstyper. Om ett element har en XAML-innehållsegenskap och typen av XAML-innehållsegenskap är en samling, behöver inte den underförstådda samlingstypen anges i markering som ett objektelement och XAML-innehållsegenskapen behöver inte anges som ett egenskapselement. Därför kan den tydliga innehållsmodellen i markeringen nu ha fler än ett underelement tilldelat som innehåll. Följande är innehållssyntax för en Panel härledd klass. Alla Panel härledda klasser etablerar XAML-innehållsegenskapen till Children, vilket kräver ett värde av typen 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>

Observera att varken egenskapselementet för Children eller elementet för UIElementCollection krävs i markeringen. Detta är en designfunktion i XAML så att rekursivt inneslutna element som definierar ett användargränssnitt representeras mer intuitivt som ett träd av kapslade element där det finns omedelbara relationer mellan överordnade och underordnade element, utan att intervenierande taggar för egenskapselement eller samlingsobjekt stör. Det går faktiskt inte att uttryckligen ange UIElementCollection som ett objektelement i uppmärkning, och detta är avsiktligt. Eftersom dess enda avsedda användning är som en implicit samling, UIElementCollection exponerar inte en offentlig parameterlös konstruktor och kan därför inte instansieras som ett objektelement.

Blanda egenskapselement och objektelement i ett objekt med en innehållsegenskap

XAML-specifikationen deklarerar att en XAML-processor kan framtvinga att objektelement som används för att fylla XAML-innehållsegenskapen i ett objektelement måste vara sammanhängande och får inte blandas. Den här begränsningen mot blandning av egenskapselement och innehåll framtvingas av WPF XAML-processorerna.

Du kan ha ett underordnat objektelement som den första omedelbara markeringen i ett objektelement. Sedan kan du introducera egenskapselement. Eller så kan du ange ett eller flera egenskapselement, sedan innehåll och sedan fler egenskapselement. Men när ett egenskapselement följer innehållet kan du inte introducera ytterligare innehåll, du kan bara lägga till egenskapselement.

Det här kravet på innehålls-/egenskapselementordning gäller inte för inre text som används som innehåll. Det är dock fortfarande ett bra markeringsformat för att hålla den inre texten sammanhängande, eftersom betydande blanksteg blir svåra att identifiera visuellt i markeringen om egenskapselement varvat med inre text.

XAML-namnområden

Inget av föregående syntaxexempel angav ett XAML-namnområde annat än XAML-standardnamnområdet. I vanliga WPF-program anges standard-XAML-namnområdet som WPF-namnområdet. Du kan ange andra XAML-namnområden än XAML-standardnamnområdet och ändå använda liknande syntax. Men var som helst där en klass namnges och inte är tillgänglig inom standard-XAML-namnområdet, måste det klassnamnet föregås av prefixet för XAML-namnområdet som är mappat till motsvarande CLR-namnområde. Är till exempel <custom:Example/> objektelementsyntax för att instansiera en instans av Example klassen, där CLR-namnområdet som innehåller den klassen (och eventuellt den externa sammansättningsinformationen som innehåller bakgrundstyper) tidigare mappades till prefixet custom .

Mer information om XAML-namnområden finns i XAML-namnområden och namnområdesmappning för WPF XAML.

Tillägg för markering

XAML definierar en programmeringsentitet för markeringstillägg som möjliggör en undanmanöver från den normala hanteringen av processorn för strängattributvärden eller element i objekt, och skjuter upp bearbetningen till en bakgrundsklass. Tecknet som identifierar ett markeringstillägg till en XAML-processor när du använder attributsyntax är den inledande klammerparentesen ({), följt av andra tecken än en avslutande klammerparentes (}). Den första strängen som följer den inledande klammerparentesen måste referera till den klass som tillhandahåller det specifika tilläggsbeteendet, där referensen kan utelämna understrängen "Extension" om delsträngen är en del av det sanna klassnamnet. Därefter kan ett enda blanksteg visas, och sedan används varje efterföljande tecken som indata av tilläggsimplementeringen tills den avslutande klammerparentesen påträffas.

.NET XAML-implementeringen använder den MarkupExtension abstrakta klassen som grund för alla påläggstillägg som stöds av WPF samt andra ramverk eller tekniker. De markup-tillägg som WPF specifikt implementerar är ofta avsedda att ge ett sätt att referera till andra befintliga objekt eller att göra senarelagda referenser till objekt som ska utvärderas vid körningstid. Till exempel utförs en enkel WPF-databindning genom att ange markeringstillägget {Binding} i stället för det värde som en viss egenskap normalt skulle ta. Många av WPF-markeringstilläggen aktiverar en attributsyntax för egenskaper där en attributsyntax annars inte skulle vara möjlig. Ett objekt är till exempel Style en relativt komplex typ som innehåller en kapslad serie med objekt och egenskaper. Formatmallar i WPF definieras vanligtvis som en resurs i en ResourceDictionary, och refereras sedan via ett av de två WPF-markeringstilläggen som begär en resurs. Markeringstillägget skjuter upp utvärderingen av egenskapsvärdet till en resursuppslagning och möjliggör att ange värdet på egenskapen Style, av typen Style, i attributsyntaxen som i följande exempel:

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

Här identifierar StaticResource klassen StaticResourceExtension som tillhandahåller implementeringen av markeringstillägget. Nästa sträng MyStyle används som indata för konstruktorn som inte är standard StaticResourceExtension , där parametern som hämtas från tilläggssträngen deklarerar den begärda ResourceKey. MyStyle förväntas vara x:Key-värdet för en Style definierad som en resurs. Begäranden om användning av StaticResource Markup-tillägget innebär att resursen ska användas för att ange Style egenskapsvärdet via statisk resurssökningslogik vid inläsningstid.

Mer information om tillägg för markering finns i Markup Extensions och WPF XAML. En referens för markeringstillägg och andra XAML-programmeringsfunktioner som är aktiverade i den allmänna .NET XAML-implementeringen finns i XAML-namnrymd (x:) Språkfunktioner. Information om WPF-specifika tillägg för markering finns i WPF XAML-tillägg.

Anslutna egenskaper

Anslutna egenskaper är ett programmeringskoncept som introduceras i XAML där egenskaper kan ägas och definieras av en viss typ, men anges som attribut eller egenskapselement för alla element. Det primära scenariot som bifogade egenskaper är avsedda för är att aktivera underordnade element i en markeringsstruktur för att rapportera information till ett överordnat element utan att kräva en omfattande delad objektmodell för alla element. Omvänt kan kopplade egenskaper användas av överordnade element för att rapportera information till underordnade element. Mer information om syftet med bifogade egenskaper och hur du skapar egna bifogade egenskaper finns i Översikt över bifogade egenskaper.

Anslutna egenskaper använder en syntax som ytligt liknar egenskapselementsyntax, eftersom du även anger en typeName.propertyName-kombinationen. Det finns två viktiga skillnader:

• Du kan använda typeName. propertyName-kombination även när du anger en bifogad egenskap via attributsyntax. Bifogade egenskaper är det enda fallet där kvalificering av egenskapsnamnet är ett krav i en attributsyntax.

• Du kan också använda egenskapselementsyntax för bifogade egenskaper. Men för typisk egenskapselementsyntax är typeName som du anger det objektelement som innehåller egenskapselementet. Om du refererar till en bifogad egenskap är typeName den klass som definierar den bifogade egenskapen, inte det innehållande objektelementet.

Anslutna händelser

Anslutna händelser är ett annat programmeringskoncept som introduceras i XAML där händelser kan definieras av en viss typ, men hanterare kan kopplas till alla objektelement. I WOF-implementeringen är ofta den typ som definierar en bifogad händelse en statisk typ som definierar en tjänst, och ibland exponeras de kopplade händelserna av ett routat händelsealias i typer som exponerar tjänsten. Hanterare för anslutna händelser anges via attributsyntax. Precis som med bifogade händelser expanderas attributsyntaxen för anslutna händelser för att tillåta ett typeName. eventName-användning , där typeName är den klass som tillhandahåller Add och Remove händelsehanteraråtkomster för den anslutna händelseinfrastrukturen, och eventName är händelsenamnet.

Anatomi för ett XAML-rotelement

I följande tabell visas ett typiskt XAML-rotelement uppdelat, som visar de specifika attributen för ett rotelement:

Valfria och icke-rekommenderade XAML-användningar

I följande avsnitt beskrivs XAML-användningar som stöds tekniskt av XAML-processorer, men som ger utförliga eller andra estetiska problem som stör XAML-filer som förblir läsbara för människor när du utvecklar program som innehåller XAML-källor.

Valfria egenskapselementanvändningar

Valfria egenskapselementanvändningar inkluderar att uttryckligen skriva ut elementinnehållsegenskaper som XAML-processorn anser vara implicita. När du till exempel deklarerar innehållet i en Menu, kan du välja att explicit deklarera samlingen av Items som ett egenskapselementtagg i Menu och placera varje <Menu.Items> inom MenuItem, istället för att använda det implicita beteendet hos XAML-processorn där alla underordnade element i en <Menu.Items> måste vara av typen Menu och placeras i MenuItem-samlingen. Ibland kan de valfria användningarna hjälpa till att visuellt klargöra objektstrukturen som representeras i markering. Eller ibland kan en explicit egenskapselementanvändning undvika markering som är tekniskt funktionell men visuellt förvirrande, till exempel kapslade tillägg för markering i ett attributvärde.

Fullständiga typeName.memberName-kvalificerade attribut

typeName.memberName-formatet för ett attribut fungerar faktiskt mer universellt än bara den dirigerade händelsen. Men i andra situationer är den formen överflödig och du bör undvika den, om så bara av skäl av markeringsstil och läsbarhet. I följande exempel är var och en av de tre referenserna Background till attributet helt likvärdiga:

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

Button.Background fungerar eftersom den kvalificerade sökningen för den egenskapen på Button lyckas (Background ärvdes från Kontroll) och Button är klassen för objektelementet eller en basklass. Control.Background fungerar eftersom Control klassen faktiskt definierar Background och Control är en Button basklass.

Följande typeName. memberName-formulärexemplet fungerar inte och visas därför kommenterat:

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

Label är en annan härledd klass av Control, och om du hade angett Label.Background i ett Label objektelement skulle den här användningen ha fungerat. Men eftersom Label inte är klassen eller basklassen för Buttonär det angivna XAML-processorbeteendet att sedan bearbeta Label.Background som en bifogad egenskap. Label.Background är inte en tillgänglig bifogad egenskap och den här användningen misslyckas.

baseTypeName.memberName Egenskapselement

På liknande sätt som typeName.memberName-syntax används för attributsyntax, används baseTypeName.memberName-syntax för egenskapselementsyntax. Följande syntax fungerar till exempel:

<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>

Här angavs egenskapselementet som Control.Background även om egenskapselementet fanns i Button.

Men precis som typeName.memberName-form för attribut är baseTypeName.memberName dålig stil i markup, och du bör undvika det.

Se även

• XAML i WPF
• XAML-namnområde (x:) språkspecifika funktioner
• WPF XAML-tillägg
• Översikt över beroende-egenskaper
• TypeConverters och XAML
• XAML och anpassade klasser för WPF