Översikt över XAML

Den här artikeln beskriver begreppen XAML-språk och XAML för Windows Runtime-apputvecklare och beskriver de olika sätten att deklarera objekt och ange attribut i XAML när det används för att skapa en Windows Runtime-app.

Vad är XAML?

XAML (Extensible Application Markup Language) är ett deklarativt språk. Mer specifikt kan XAML initiera objekt och ange egenskaper för objekt med hjälp av en språkstruktur som visar hierarkiska relationer mellan flera objekt och en bakgrundstypkonvention som stöder tillägg av typer. Du kan skapa synliga gränssnittselement i den deklarativa XAML-markeringen. Du kan sedan associera en separat kod bakom fil för varje XAML-fil som kan svara på händelser och ändra de objekt som du ursprungligen deklarerar i XAML.

XAML-språket stöder utbyte av källor mellan olika verktyg och roller i utvecklingsprocessen, till exempel utbyte av XAML-källor mellan designverktyg och en interaktiv utvecklingsmiljö (IDE) eller mellan primära utvecklare och lokaliseringsutvecklare. Genom att använda XAML som utbytesformat kan designerroller och utvecklarroller hållas åtskilda eller sammanföras, och designers och utvecklare kan iterera under produktionen av en app.

När du ser dem som en del av dina Windows Runtime-appprojekt är XAML-filer XML-filer med filnamnstillägget .xaml.

Grundläggande XAML-syntax

XAML har en grundläggande syntax som bygger på XML. Per definition måste giltig XAML också vara giltig XML. Men XAML har också syntaxbegrepp som tilldelas en annan och mer fullständig betydelse samtidigt som de fortfarande är giltiga i XML enligt XML 1.0-specifikationen. XAML stöder till exempel syntax för egenskapselement, där egenskapsvärden kan anges i element i stället för som strängvärden i attribut eller som innehåll. För vanlig XML är ett XAML-egenskapselement ett element med en punkt i namnet, så det är giltigt för vanlig XML men har inte samma betydelse.

XAML och Visual Studio

Microsoft Visual Studio hjälper dig att skapa en giltig XAML-syntax, både i XAML-textredigeraren och i den mer grafiskt orienterade XAML-designytan. När du skriver XAML för din app med Visual Studio ska du inte oroa dig för mycket för syntaxen med varje tangenttryckning. IDE uppmuntrar giltig XAML-syntax genom att tillhandahålla tips om automatisk komplettering, visa förslag i Microsoft IntelliSense-listor och listrutor, visa gränssnittselementbibliotek i fönstret Verktygslåda eller andra tekniker. Om detta är din första erfarenhet av XAML kan det fortfarande vara användbart att känna till syntaxreglerna och särskilt den terminologi som ibland används för att beskriva begränsningarna eller valen när du beskriver XAML-syntaxen i referens eller andra ämnen. De fina punkterna i XAML-syntaxen beskrivs i ett separat ämne, XAML-syntaxguide.

XAML-namnområden

I allmän programmering är ett namnområde ett organisationskoncept som avgör hur identifierare för programmeringsentiteter tolkas. Med hjälp av namnområden kan ett programmeringsramverk separera användardefinierade identifierare från ramverksdeklarerade identifierare, skilja identifierare genom namnområdeskvalifikationer, tillämpa regler för omfångsnamn och så vidare. XAML har ett eget XAML-namnområdeskoncept som tjänar detta syfte för XAML-språket. Så här tillämpar och utökar XAML begreppen för XML-språknamnområde:

• XAML använder xmlns för reserverade XML-attribut för namnområdesdeklarationer. Värdet för attributet är vanligtvis en URI (Uniform Resource Identifier), vilket är en konvention som ärvs från XML.
• XAML använder prefix i deklarationer för att deklarera namnområden som inte är standard och prefixanvändningar i element och attribut refererar till det namnområdet.
• XAML har ett koncept för ett standardnamnområde, vilket är det namnområde som används när det inte finns något prefix i en användning eller deklaration. Standardnamnområdet kan definieras på olika sätt för varje XAML-programmeringsramverk.
• Namnområdesdefinitioner ärvs i en XAML-fil eller -konstruktion, från överordnat element till underordnat element. Om du till exempel definierar ett namnområde i rotelementet i en XAML-fil ärver alla element i filen den namnområdesdefinitionen. Om ett element längre in på sidan omdefinierar namnområdet ärver elementets underordnade element den nya definitionen.
• Attribut för ett element ärver elementets namnområden. Det är ganska ovanligt att se prefix på XAML-attribut.

En XAML-fil deklarerar nästan alltid ett XAML-standardnamnområde i rotelementet. XAML-standardnamnområdet definierar vilka element du kan deklarera utan att kvalificera dem med ett prefix. För typiska Windows Runtime-appprojekt innehåller det här standardnamnområdet all inbyggd XAML-vokabulär för Windows Runtime som används för gränssnittsdefinitioner: standardkontroller, textelement, XAML-grafik och animeringar, stödtyper för databindning och formatering. De flesta XAML-appar som du skriver för Windows Runtime-appar kan därför undvika att använda XAML-namnområden och prefix när du refererar till vanliga gränssnittselement.

Här är ett kodfragment som visar en mallskapad Page som rot för startsidan i en app (som endast visar den inledande taggen och är förenklad). Den deklarerar standardnamnområdet och även x-namnområdet (som vi ska förklara härnäst).

<Page
    x:Class="Application1.BlankPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>

XAML-språkets XAML-namnområde

Ett specifikt XAML-namnområde som deklareras i nästan varje Windows Runtime XAML-fil är XAML-språknamnområdet. Det här namnområdet innehåller element och begrepp som definieras av XAML-språkspecifikationen. Enligt konventionen mappas XAML-språks XAML-namnområdet till prefixet "x". Standardprojekt- och filmallarna för Windows Runtime-app-projekt definierar alltid både XAML-standardnamnområdet (inget prefix, bara xmlns=) och XAML-språkets XAML-namnområde (prefixet "x") som en del av rotelementet.

XAML-namnområdet x-prefix/XAML-språk innehåller flera programmeringskonstruktioner som du ofta använder i XAML. Här är de vanligaste:

Andra programmeringskonstruktioner i XAML-språkets XAML-namnområde finns men är inte lika vanliga.

Mappa anpassade typer till XAML-namnområden

En av de mest kraftfulla aspekterna av XAML som språk är att det är enkelt att utöka XAML-vokabulären för dina Windows Runtime-appar. Du kan definiera dina egna anpassade typer i appens programmeringsspråk och sedan referera till dina anpassade typer i XAML-markering. Stöd för tillägg via anpassade typer är i grunden inbyggt i hur XAML-språket fungerar. Ramverk eller apputvecklare ansvarar för att skapa de stödobjekt som XAML refererar till. Varken ramverk eller apputvecklaren är bundna av specifikationer för vad objekten i deras vokabulärer representerar eller gör utöver de grundläggande XAML-syntaxreglerna. (Det finns vissa förväntningar på vad XAML-språkets XAML-namnområdestyper ska göra, men Windows Runtime ger allt nödvändigt stöd.)

Om du använder XAML för typer som kommer från andra bibliotek än Windows Runtime-kärnbibliotek och metadata måste du deklarera och mappa ett XAML-namnområde med ett prefix. Använd prefixet i elementanvändningar för att referera till de typer som har definierats i biblioteket. Du deklarerar prefixmappningar som xmlns-attribut , vanligtvis i ett rotelement tillsammans med de andra XAML-namnområdesdefinitionerna.

Om du vill skapa en egen namnområdesdefinition som refererar till anpassade typer anger du först nyckelordet xmlns:, sedan det prefix du vill använda. Värdet för attributet måste innehålla nyckelordet med: som den första delen av värdet. Resten av värdet är ett strängvärde som refererar till det specifika namnområdet i din kodmiljö som innehåller dina anpassade typer.

Prefixet definierar den markeringstoken som används för att referera till XAML-namnområdet i resten av pålägget i XAML-filen. Ett kolontecken (:) går mellan prefixet och entiteten som ska refereras i XAML-namnområdet.

Attributsyntaxen för att mappa ett prefix myTypes till namnområdet myCompany.myTypes är till exempel: xmlns:myTypes="using:myCompany.myTypes", och en representativ elementanvändning är: <myTypes:CustomButton/>

Mer information om hur du mappar XAML-namnområden för anpassade typer, inklusive särskilda överväganden för Visual C++-komponenttillägg (C++/CX) finns i XAML-namnområden och namnområdesmappning.

Andra XAML-namnområden

Du ser ofta XAML-filer som definierar prefixen "d" (för designernamnområdet) och "mc" (för markeringskompatibilitet). I allmänhet är dessa för infrastrukturstöd eller för att aktivera scenarier i ett designtidsverktyg. Mer information finns i avsnittet "Andra XAML-namnområden" i avsnittet XAML-namnområden.

Tillägg för markering

Markeringstillägg är ett XAML-språkkoncept som ofta används i Windows Runtime XAML-implementeringen. Markeringstillägg representerar ofta någon form av "genväg" som gör det möjligt för en XAML-fil att komma åt ett värde eller beteende som inte bara deklarerar element baserat på bakgrundstyper. Vissa markeringstillägg kan ange egenskaper med enkla strängar eller med ytterligare kapslade element, med målet att effektivisera syntaxen eller factoring mellan olika XAML-filer.

I XAML-attributsyntax används klammerparenteserna "{" och "}" för att indikera användningen av en XAML-markupförlängning. Den här användningen instruerar XAML-bearbetningen att komma ifrån den allmänna behandlingen av att behandla attributvärden som antingen en literalsträng eller ett direkt strängkonvertert värde. I stället anropar en XAML-parser kod som ger beteende för det specifika markeringstillägget, och den koden ger ett alternativt objekt eller beteenderesultat som XAML-parsaren behöver. Markeringstillägg kan ha argument som följer namnet på markeringstillägget och som också finns i klammerparenteserna. Vanligtvis ger ett utvärderat markeringstillägg ett objektreturvärde. Under parsningen infogas det returvärdet i positionen i objektträdet där markeringstilläggsanvändningen fanns i käll-XAML.

Windows Runtime XAML stöder dessa påläggstillägg som definieras under XAML-standardnamnområdet och som förstås av Windows Runtime XAML-parsern:

• {x:Bind}: stöder databindning, som skjuter upp egenskapsutvärdering till körning genom att köra specialkod, som genereras vid kompileringstidpunkten. Det här markeringstillägget har stöd för en mängd olika argument.
• {Binding}: stöder databindning, som skjuter upp egenskapsutvärdering till körning genom att utföra generell inspektion av körningsobjekt. Det här markeringstillägget har stöd för en mängd olika argument.
• {StaticResource}: stöder referenser till resursvärden som definieras i en ResourceDictionary. Dessa resurser kan finnas i en annan XAML-fil men måste slutligen hittas av XAML-parsern vid inläsningen. Argumentet för en {StaticResource} användning identifierar nyckeln (namnet) för en nyckelad resurs i en ResourceDictionary.
• {ThemeResource}: liknar {StaticResource} men kan svara på ändringar i körningstemat. {ThemeResource} visas ganska ofta i XAML-standardmallarna för Windows Runtime, eftersom de flesta av dessa mallar är utformade för kompatibilitet med användaren som byter tema medan appen körs.
• {TemplateBinding}: ett specialfall med {Binding} som stöder kontrollmallar i XAML och deras eventuella användning vid körning.
• {RelativeSource}: aktiverar en viss form av mallbindning där värden kommer från den överordnade mallen.
• {CustomResource}: för avancerade resurssökningsscenarier.

Windows Runtime har också stöd för markeringstillägget {x:Null}. Du använder detta för att ange Nullable-värden till null i XAML. Du kan till exempel använda detta i en kontrollmall för en kryssruta, vilket tolkar null som ett obestämt kontrolltillstånd (utlöser det visuella tillståndet "Obestämd").

Ett markeringstillägg returnerar vanligtvis en befintlig instans från någon annan del av objektdiagrammet för appen eller defers ett värde som ska köras. Eftersom du kan använda ett markeringstillägg som ett attributvärde, och det är den typiska användningen, ser du ofta markeringstillägg som tillhandahåller värden för egenskaper av referenstyp som annars kan ha krävt en egenskapselementsyntax.

Här är till exempel syntaxen för att referera till en återanvändbar Style från en resursordbok: <Button Style="{StaticResource SearchButtonStyle}"/>. En stil är en referenstyp, inte ett enkelt värde, så utan användning av {StaticResource} skulle du ha behövt ett <Button.Style> egenskapselement och en <Style> definition i det för att sätta egenskapen FrameworkElement.Style.

Med hjälp av markeringstillägg kan alla egenskaper som kan anges i XAML eventuellt anges i attributsyntaxen. Du kan använda attributsyntax för att ange referensvärden för en egenskap även om den annars inte stöder en attributsyntax för direkt objekt-instansiering. Eller så kan du aktivera specifika beteenden som skjuter upp det allmänna kravet på att XAML-egenskaper fylls i av värdetyper eller av nyligen skapade referenstyper.

För att illustrera anger nästa XAML-exempel värdet för egenskapen FrameworkElement.Style för en kantlinje med hjälp av attributsyntax. Egenskapen FrameworkElement.Style tar en instans av klassen Style , en referenstyp som som standard inte kunde skapas med hjälp av en attributsyntaxsträng. Men i det här fallet refererar attributet till ett visst markeringstillägg, StaticResource. När markeringstillägget bearbetas returneras en referens till ett formatelement som tidigare definierades som en nyckelresurs i en resursordlista.

<Canvas.Resources>
  <Style TargetType="Border" x:Key="PageBackground">
    <Setter Property="BorderBrush" Value="Blue"/>
    <Setter Property="BorderThickness" Value="5"/>
  </Style>
</Canvas.Resources>
...
<Border Style="{StaticResource PageBackground}">
  ...
</Border>

Du kan kapsla markeringstillägg. Det innersta markup-tillägget utvärderas först.

På grund av markeringstillägg behöver du särskild syntax för ett literalt {-värde i ett attribut. Mer information finns i XAML-syntaxguide.

Evenemang

XAML är ett deklarativt språk för objekt och deras egenskaper, men det innehåller även en syntax för att koppla händelsehanterare till objekt i markering. XAML-händelsesyntaxen kan sedan integrera XAML-deklarerade händelser via Windows Runtime-programmeringsmodellen. Du anger namnet på händelsen som ett attributnamn på objektet där händelsen hanteras. För attributvärdet anger du namnet på en händelsehanterarfunktion som du definierar i kod. XAML-processorn använder det här namnet för att skapa en ombudsrepresentation i det inlästa objektträdet och lägger till den angivna hanteraren i en intern hanteringslista. Nästan alla Windows Runtime-appar definieras av både markerings- och kod-bakomsidor.

Här är ett enkelt exempel. Klassen Button stöder en händelse med namnet Klicka. Du kan skriva en hanterare för Klicka som kör kod som ska anropas när användaren klickar på Knappen. I XAML anger du Klicka som ett attribut på knappen. Ange en sträng som är hanterarens metodnamn för attributvärdet.

<Button Click="showUpdatesButton_Click">Show updates</Button>

När du kompilerar förväntar sig kompilatorn nu att det kommer att finnas en metod med namnet showUpdatesButton_Click definierad i filen bakom koden, i namnområdet som deklareras i XAML-sidans x:Class-värde . Den metoden måste också uppfylla delegeringskontraktet för Click-händelsen. Till exempel:

namespace App1
{
    public sealed partial class MainPage: Page {
        ...
        private void showUpdatesButton_Click (object sender, RoutedEventArgs e) {
            //your code
        }
    }
}

' Namespace included at project level
Public NotInheritable Class MainPage
    Inherits Page
        ...
        Private Sub showUpdatesButton_Click (sender As Object, e As RoutedEventArgs e)
            ' your code
        End Sub
    ...
End Class

namespace winrt::App1::implementation
{
    struct MainPage : MainPageT<MainPage>
    {
        ...
        void showUpdatesButton_Click(Windows::Foundation::IInspectable const&, Windows::UI::Xaml::RoutedEventArgs const&);
    };
}

// .h
namespace App1
{
    public ref class MainPage sealed {
        ...
    private:
        void showUpdatesButton_Click(Object^ sender, RoutedEventArgs^ e);
    };
}

I ett projekt skrivs XAML som en .xaml-fil och du använder det språk du föredrar (C#, Visual Basic, C++/CX) för att skriva en kod bakom fil. När en XAML-fil markup-kompileras som en del av en byggåtgärd för projektet identifieras platsen för XAML-kod-bakom-filen för varje XAML-sida genom att specificera ett namnområde och en klass som x:Class-attributet för rotelementet på XAML-sidan. Mer information om hur dessa mekanismer fungerar i XAML och hur de relaterar till programmerings- och programmodeller finns i Översikt över händelser och routade händelser.

Resursordböcker

Att skapa en ResourceDictionary är en vanlig uppgift som vanligtvis utförs genom att skapa en resursordlista som ett område på en XAML-sida eller en separat XAML-fil. Resursordlistor och hur du använder dem är ett större konceptuellt område som ligger utanför omfånget för det här ämnet. Mer information finns i Resursdictionary- och XAML-resursreferenser.

XAML och XML

XAML-språket baseras i grunden på XML-språket. Men XAML utökar XML avsevärt. I synnerhet behandlar det begreppet schema på ett helt annat sätt på grund av dess relation till bakgrundstypskonceptet och lägger till språkelement som bifogade medlemmar och tillägg för markering. xml:lang är giltigt i XAML, men påverkar körningen snarare än parsningsbeteendet, och reduceras vanligtvis till en egenskap på framework-nivå. Mer information finns i FrameworkElement.Language. xml:base är giltigt i markupkod men ignoreras av parsern. xml:space är giltigt, men är bara relevant för scenarier som beskrivs i avsnittet XAML och blanksteg. Kodningsattributet är giltigt i XAML. Endast UTF-8- och UTF-16-kodningar stöds. UTF-32-kodning stöds inte.

Skiftlägeskänslighet i XAML

XAML är skiftlägeskänsligt. Detta är en annan konsekvens av att XAML baseras på XML, vilket är skiftlägeskänsligt. Namnen på XAML-element och -attribut är skiftlägeskänsliga. Värdet för ett attribut är potentiellt skiftlägeskänsligt. Detta beror på hur attributvärdet hanteras för vissa egenskaper. Till exempel, om attributvärdet deklarerar ett medlemsnamn för en uppräkning, är det inbyggda beteendet som typkonverterar en medlemsnamnsträng för att returnera medlemsvärdet inte skiftlägeskänsligt. Däremot behandlar värdet för egenskapen Namn, och verktygsmetoder för att arbeta med objekt baserat på namnet som egenskapen Namn deklarerar, namnsträngen som skiftlägeskänslig.

XAML-namnrymder

XAML-språket definierar ett begrepp för ett XAML-namnskop. Begreppet XAML-namnskop påverkar hur XAML-processorer ska hantera värdet för x:Name eller Name som tillämpas på XAML-element, särskilt de omfång där namn ska användas för att vara unika identifierare. XAML-namnskop beskrivs mer detaljerat i ett separat ämne. se XAML-namnskop.

XAML:s roll i utvecklingsprocessen

XAML spelar flera viktiga roller i apputvecklingsprocessen.

• XAML är det primära formatet för att deklarera en apps användargränssnitt och element i användargränssnittet, om du programmerar med C#, Visual Basic eller C++/CX. Normalt representerar minst en XAML-fil i projektet en sidmetafor i din app för det ursprungligen visade användargränssnittet. Ytterligare XAML-filer kan deklarera ytterligare sidor för navigeringsgränssnittet. Andra XAML-filer kan deklarera resurser, till exempel mallar eller formatmallar.
• Du använder XAML-formatet för att deklarera format och mallar som tillämpas på kontroller och användargränssnitt för en app.
• Du kan använda formatmallar och mallar för att redigera befintliga kontroller, eller om du definierar en kontroll som tillhandahåller en standardmall som en del av ett kontrollpaket. När du använder den för att definiera stilar och mallar deklareras relevant XAML ofta som en fristående XAML-fil med en ResourceDictionary-rot.
• XAML är det vanliga formatet för designerstöd för att skapa appgränssnitt och utbyta användargränssnittsdesign mellan olika designerappar. Framför allt kan XAML för appen bytas mellan olika XAML-designverktyg (eller designfönster inom verktyg).
• Flera andra tekniker definierar också det grundläggande användargränssnittet i XAML. I förhållande till Windows Presentation Foundation (WPF) XAML och Microsoft Silverlight XAML använder XAML för Windows Runtime samma URI för sitt delade XAML-standardnamnområde. XAML-vokabulären för Windows Runtime överlappar avsevärt med vokabulären XAML-for-UI som också används av Silverlight och i något mindre utsträckning av WPF. Därför främjar XAML en effektiv migreringsväg för användargränssnittet som ursprungligen definierades för prekursortekniker som också använde XAML.
• XAML definierar det visuella utseendet på ett användargränssnitt och en associerad kod bakom-fil definierar logiken. Du kan justera användargränssnittets design utan att göra ändringar i logiken i bakomliggande kod. XAML förenklar arbetsflödet mellan designers och utvecklare.
• På grund av den visuella designerns och designytans omfattande stöd för XAML-språket stöder XAML snabba UI-prototyper i de tidiga utvecklingsfaserna.

Beroende på din egen roll i utvecklingsprocessen kanske du inte interagerar mycket med XAML. I vilken utsträckning du interagerar med XAML-filer beror också på vilken utvecklingsmiljö du använder, om du använder interaktiva designmiljöfunktioner som verktygslådor och egenskapsredigerare samt omfånget och syftet med din Windows Runtime-app. Det är dock troligt att du under utvecklingen av appen redigerar en XAML-fil på elementnivå med hjälp av en text- eller XML-redigerare. Med den här informationen kan du med säkerhet redigera XAML i en text- eller XML-representation och upprätthålla giltigheten för XAML-filens deklarationer och syfte när den används av verktyg, kompileringsåtgärder för markering eller körningsfasen i windows Runtime-appen.

Optimera XAML för belastningsprestanda

Här följer några tips för att definiera gränssnittselement i XAML med hjälp av metodtips för prestanda. Många av dessa tips gäller användning av XAML-resurser, men finns här i den allmänna XAML-översikten för enkelhetens skull. Mer information om XAML-resurser finns i Resursdictionary- och XAML-resursreferenser. Några fler tips om prestanda, inklusive XAML som avsiktligt visar några av de dåliga prestandametoder som du bör undvika i XAML, finns i Optimera din XAML-markering.

• Om du använder samma färgborste ofta i XAML definierar du en SolidColorBrush som en resurs i stället för att använda en namngiven färg som ett attributvärde varje gång.
• Om du använder samma resurs på mer än en användargränssnittssida bör du överväga att definiera den i Application.Resources i stället för på varje sida. Om bara en sida använder en resurs ska du däremot inte definiera den i Application.Resources och i stället bara definiera den för den sida som behöver den. Detta är bra både för XAML-factoring när du utformar din app och för prestanda under XAML-parsning.
• Kontrollera om det finns några oanvända resurser som din app-paket kan innehålla (en resurs som har en nyckel, men det finns ingen StaticResource-referens i din app som använder den). Ta bort dessa från XAML innan du släpper appen.
• Om du använder separata XAML-filer som tillhandahåller designresurser (Sammanfogade ordlistor) bör du överväga att kommentera eller ta bort oanvända resurser från dessa filer. Även om du har en delad XAML-startpunkt som du använder i mer än en app eller som tillhandahåller gemensamma resurser för hela din app, är det fortfarande din app som paketera XAML-resurserna varje gång och eventuellt måste läsa in dem.
• Definiera inte gränssnittselement som du inte behöver för komposition och använd standardkontrollmallarna när det är möjligt (dessa mallar har redan testats och verifierats för belastningsprestanda).
• Använd containrar som Kantlinje i stället för avsiktliga övertrasseringar av gränssnittselement. Rita i princip inte samma pixel flera gånger. Mer information om överdragning och hur du testar för det finns i DebugSettings.IsOverdrawHeatMapEnabled.
• Använd standardobjektmallarna för ListView eller GridView. dessa har särskild presentatörslogik som löser prestandaproblem när du skapar det visuella trädet för ett stort antal listobjekt.

Felsök XAML

Eftersom XAML är ett markeringsspråk är vissa av de typiska strategierna för felsökning i Microsoft Visual Studio inte tillgängliga. Det finns till exempel inget sätt att ange en brytpunkt i en XAML-fil. Det finns dock andra tekniker som kan hjälpa dig att felsöka problem med användargränssnittsdefinitioner eller annan XAML-markering medan du fortfarande utvecklar din app.

När det finns problem med en XAML-fil är det vanligaste resultatet att ett system eller din app utlöser ett XAML-parsningsfel. När det finns ett XAML-parsningsfel kunde XAML som lästes in av XAML-parsern inte skapa ett giltigt objektträd. I vissa fall, till exempel när XAML representerar den första "sidan" i ditt program som läses in som det visuella rotobjektet, kan XAML-parsningsfelet inte återställas.

XAML redigeras ofta inom en IDE som Visual Studio och en av dess XAML-designytor. Visual Studio kan ofta tillhandahålla validering av designtid och felkontroll av en XAML-källa när du redigerar den. Det kan till exempel visa "squiggles" i XAML-textredigeraren så fort du skriver ett felaktigt attributvärde, och du behöver inte ens vänta på ett XAML-kompileringspass för att se att något är fel med användargränssnittsdefinitionen.

När appen faktiskt körs, om några XAML-parsningsfel inte har identifierats vid designtillfället, rapporteras dessa av CLR (Common Language Runtime) som en XamlParseException. Mer information om vad du kan göra för en körning av XamlParseException finns i Undantagshantering för Windows Runtime-appar i C# eller Visual Basic.

Mer information om felsökning av en Windows Runtime-app finns i Starta en felsökningssession.