Overzicht van XAML

In dit artikel worden de XAML-taal en XAML-concepten geïntroduceerd voor de ontwikkelaars van Windows Runtime-apps en worden de verschillende manieren beschreven om objecten te declareren en kenmerken in te stellen in XAML, omdat deze worden gebruikt voor het maken van een Windows Runtime-app.

Wat is XAML?

Extensible Application Markup Language (XAML) is een declaratieve taal. XAML kan met name objecten initialiseren en eigenschappen van objecten instellen met behulp van een taalstructuur met hiërarchische relaties tussen meerdere objecten en een conventie voor het backingtype die uitbreiding van typen ondersteunt. U kunt zichtbare UI-elementen maken in de declaratieve XAML-opmaak. Vervolgens kunt u een afzonderlijk code-behind-bestand koppelen voor elk XAML-bestand dat kan reageren op gebeurtenissen en de objecten bewerken die u oorspronkelijk in XAML declareert.

De XAML-taal ondersteunt uitwisseling van bronnen tussen verschillende hulpprogramma's en rollen in het ontwikkelingsproces, zoals het uitwisselen van XAML-bronnen tussen ontwerphulpprogramma's en een interactieve ontwikkelomgeving (IDE) of tussen primaire ontwikkelaars en lokalisatieontwikkelaars. Door XAML te gebruiken als het uitwisselingsformaat, kunnen ontwerprollen en ontwikkelaarsrollen gescheiden of bijeengebracht worden, en kunnen ontwerpers en ontwikkelaars tijdens de productie van een app itereren.

Wanneer u ze ziet als onderdeel van uw Windows Runtime-app-projecten, zijn XAML-bestanden XML-bestanden met de xaml-bestandsextensie.

Eenvoudige XAML-syntaxis

XAML heeft een basissyntaxis die voortbouwt op XML. Geldige XAML moet per definitie ook geldige XML zijn. Maar XAML heeft ook syntaxisconcepten die een andere en volledigere betekenis hebben, terwijl ze nog steeds geldig zijn in XML volgens de XML 1.0-specificatie. XAML ondersteunt bijvoorbeeld syntaxis van eigenschapselementen, waarbij eigenschapswaarden kunnen worden ingesteld binnen elementen in plaats van tekenreekswaarden in kenmerken of als inhoud. Voor gewone XML is een XAML-eigenschapselement een element met een punt in de naam, dus het is geldig voor gewone XML, maar heeft niet dezelfde betekenis.

XAML en Visual Studio

Microsoft Visual Studio helpt u bij het produceren van geldige XAML-syntaxis, zowel in de XAML-teksteditor als in het meer grafisch georiënteerde XAML-ontwerpoppervlak. Wanneer u XAML schrijft voor uw app met Visual Studio, hoeft u zich geen zorgen te maken over de syntaxis met elke toetsaanslag. De IDE stimuleert de correcte XAML-syntaxis door autocompletesuggesties te bieden, suggesties te tonen in Microsoft IntelliSense-lijsten en dropdownlijsten, en UI-elementbibliotheken te laten zien in het venster Werkset, of door andere technieken. Als dit uw eerste ervaring is met XAML, is het misschien nog steeds handig om de syntaxisregels te kennen en met name de terminologie die soms wordt gebruikt om de beperkingen of keuzes te beschrijven bij het beschrijven van de XAML-syntaxis in verwijzing of andere onderwerpen. De fijne punten van de XAML-syntaxis worden behandeld in een afzonderlijk onderwerp, de XAML-syntaxishandleiding.

XAML-naamruimten

In het algemeen is een naamruimte een organisatieconcept dat bepaalt hoe id's voor programmeerentiteiten worden geïnterpreteerd. Met behulp van naamruimten kan een programmeerframework door de gebruiker gedeclareerde id's scheiden van framework-gedeclareerde id's, id's ondubbelzinnig maken via naamruimtekwalificaties, regels afdwingen voor bereiknamen, enzovoort. XAML heeft een eigen XAML-naamruimteconcept dat dit doel voor de XAML-taal dient. Hier ziet u hoe XAML van toepassing is en de concepten van de XML-taalnaamruimte uitbreidt:

XAML maakt gebruik van het gereserveerde XML-attribuut xmlns voor naamruimtedeclaraties. De waarde van het kenmerk is doorgaans een URI (Uniform Resource Identifier), een conventie die is overgenomen van XML.
XAML gebruikt voorvoegsels in declaraties om niet-standaardnaamruimten te declareren en gebruik van voorvoegsels in elementen en kenmerken verwijzen naar die naamruimte.
XAML heeft een concept van een standaardnaamruimte, de naamruimte die wordt gebruikt wanneer er geen voorvoegsel bestaat in een gebruik of declaratie. De standaardnaamruimte kan anders worden gedefinieerd voor elk XAML-programmeerframework.
Naamruimtedefinities nemen over in een XAML-bestand of -constructie, van bovenliggend element naar onderliggend element. Als u bijvoorbeeld een naamruimte definieert in het hoofdelement van een XAML-bestand, nemen alle elementen in dat bestand die naamruimtedefinitie over. Als een element verder in de pagina de naamruimte opnieuw definieert, nemen de onderliggende elementen de nieuwe definitie over.
Kenmerken van een element nemen de naamruimten van het element over. Het is vrij ongebruikelijk dat er voorvoegsels worden weergegeven voor XAML-kenmerken.

Een XAML-bestand declareert bijna altijd een standaard XAML-naamruimte in het hoofdelement. De standaardnaamruimte XAML definieert welke elementen u kunt declareren zonder deze te kwalificeren door een voorvoegsel. Voor typische Windows Runtime-app-projecten bevat deze standaardnaamruimte alle ingebouwde XAML-woordenlijst voor de Windows Runtime die wordt gebruikt voor UI-definities: de standaardbesturingselementen, tekstelementen, XAML-afbeeldingen en animaties, gegevensbinding en stijlondersteuningstypen, enzovoort. De meeste XAML die u voor Windows Runtime-apps schrijft, kunnen dus voorkomen dat u XAML-naamruimten en voorvoegsels gebruikt wanneer wordt verwezen naar algemene UI-elementen.

Hier volgt een fragment met een door een sjabloon gemaakte paginahoofdmap van de eerste pagina voor een app (met alleen de openingstag en vereenvoudigd). Het declareert de standaardnaamruimte en ook de x-naamruimte (die we hierna zullen uitleggen).

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

De XAML-naamruimte voor de XAML-taal

Een bepaalde XAML-naamruimte die in bijna elk Windows Runtime XAML-bestand wordt gedeclareerd, is de XAML-taalnaamruimte. Deze naamruimte bevat elementen en concepten die zijn gedefinieerd door de XAML-taalspecificatie. Conventioneel wordt de XAML-taalnaamruimte toegewezen aan het voorvoegsel 'x'. De standaardproject- en bestandssjablonen voor Windows Runtime-app-projecten definiëren altijd zowel de standaard XAML-naamruimte (geen voorvoegsel, alleen xmlns=) als de XAML-naamruimte (voorvoegsel 'x') als onderdeel van het hoofdelement.

Het voorvoegsel 'x' /XAML-taal XAML-naamruimte bevat verschillende programmeerconstructies die u vaak in uw XAML gebruikt. Dit zijn de meest voorkomende:

Termijn	Description
x:Key	Hiermee stelt u een unieke door de gebruiker gedefinieerde sleutel in voor elke resource in een XAML ResourceDictionary. De tokentekenreeks van de sleutel is het argument voor de staticResource-markeringsextensie en u gebruikt deze sleutel later om de XAML-resource op te halen uit een ander XAML-gebruik elders in de XAML van uw app.
x:Klasse	Hiermee geeft u de codenaamruimte en codeklassenaam op voor de klasse die code-behind biedt voor een XAML-pagina. Hiermee wordt de klasse genoemd die wordt gemaakt of toegevoegd door de buildacties wanneer u uw app bouwt. Deze buildacties ondersteunen de XAML-markeringscompilator en combineren uw markeringen en code-behind wanneer de app wordt gecompileerd. U moet een dergelijke klasse hebben om code-behind te ondersteunen voor een XAML-pagina. Window.Content in het standaardactiveringsmodel van Windows Runtime.
x:Naam	Hiermee geeft u een runtime-objectnaam op voor het exemplaar dat bestaat in runtimecode nadat een objectelement dat is gedefinieerd in XAML is verwerkt. U kunt het instellen van x:Name in XAML beschouwen als het declareren van een benoemde variabele in code. Zoals u later leert, gebeurt dat precies wanneer uw XAML wordt geladen als onderdeel van een Windows Runtime-app. NoteName is een vergelijkbare eigenschap in het framework, maar niet alle elementen ondersteunen deze. Gebruik x:Name voor elementidentificatie wanneer FrameworkElement.Name niet wordt ondersteund voor dat elementtype.
x:Uid	Identificeert elementen die gelokaliseerde resources moeten gebruiken voor sommige eigenschapswaarden. Zie quickstart: Ui-resources vertalen voor meer informatie over het gebruik van x:Uid.
XAML-intrinsieke gegevenstypen	Deze typen kunnen waarden opgeven voor eenvoudige waardetypen wanneer dat vereist is voor een kenmerk of resource. Deze intrinsieke typen komen overeen met de eenvoudige waardetypen die doorgaans worden gedefinieerd als onderdeel van de intrinsieke definities van elke programmeertaal. U hebt bijvoorbeeld een object nodig dat een echte Booleaanse waarde vertegenwoordigt voor gebruik in een ObjectAnimationUsingKeyFrames storyboarded visualstatus. Voor die waarde in XAML gebruikt u het intrinsieke type x:Boolean als objectelement, zoals: `<x:Boolean>True</x:Boolean>`

Andere programmeerconstructies in de XAML-taal XAML-naamruimte bestaan, maar zijn niet zo gebruikelijk.

Aangepaste typen toewijzen aan XAML-naamruimten

Een van de krachtigste aspecten van XAML als taal is dat het eenvoudig is om de XAML-woordenlijst voor uw Windows Runtime-apps uit te breiden. U kunt uw eigen aangepaste typen definiëren in de programmeertaal van uw app en vervolgens verwijzen naar uw aangepaste typen in XAML-markeringen. Ondersteuning voor extensie via aangepaste typen is fundamenteel ingebouwd in de werking van de XAML-taal. Frameworks of app-ontwikkelaars zijn verantwoordelijk voor het maken van de back-upobjecten waarnaar XAML verwijst. Frameworks en de app-ontwikkelaar zijn niet gebonden aan specificaties van wat de objecten in hun woordenlijsten vertegenwoordigen of doen buiten de basisregels voor XAML-syntaxis. (Er zijn enkele verwachtingen van wat de XAML-taal XAML-naamruimtetypen moeten doen, maar de Windows Runtime biedt alle benodigde ondersteuning.)

Als u XAML gebruikt voor typen die afkomstig zijn van andere bibliotheken dan de Windows Runtime-kernbibliotheken en metagegevens, moet u een XAML-naamruimte declareren en toewijzen met een voorvoegsel. Gebruik dat voorvoegsel in elementgebruik om te verwijzen naar de typen die in uw bibliotheek zijn gedefinieerd. U declareert voorvoegseltoewijzingen als xmlns-kenmerken , meestal in een hoofdelement, samen met de andere XAML-naamruimtedefinities.

Als u uw eigen naamruimtedefinitie wilt maken die verwijst naar aangepaste typen, geeft u eerst de xmlns voor trefwoorden op, en vervolgens het gewenste voorvoegsel. De waarde van dat kenmerk moet het trefwoord bevatten met behulp van: als het eerste deel van de waarde. De rest van de waarde is een tekenreekstoken dat verwijst naar de specifieke code-ondersteunende naamruimte die uw aangepaste typen bevat, volgens de naam.

Het voorvoegsel definieert het opmaaktoken dat wordt gebruikt om te verwijzen naar die XAML-naamruimte in de rest van de markering in dat XAML-bestand. Een dubbele punt (:) gaat tussen het voorvoegsel en de entiteit waarnaar moet worden verwezen in de XAML-naamruimte.

De syntaxis van het kenmerk voor het toewijzen van een voorvoegsel myTypes aan de naamruimte myCompany.myTypes is bijvoorbeeld: xmlns:myTypes="using:myCompany.myTypes"en een representatief elementgebruik is: <myTypes:CustomButton/>

Zie XAML-naamruimten en naamruimtetoewijzingen voor aangepaste typen voor meer informatie over het toewijzen van XAML-naamruimten, waaronder speciale overwegingen voor Visual C++-onderdeelextensies (C++/CX).

Andere XAML-naamruimten

Vaak ziet u XAML-bestanden die de voorvoegsels 'd' (voor de ontwerpnaamruimte) en 'mc' definiëren (voor compatibiliteit met markeringen). Over het algemeen zijn dit voor ondersteuning van infrastructuur of om scenario's in te schakelen in een ontwerphulpprogramma. Zie de sectie Overige XAML-naamruimten van het onderwerp XAML-naamruimten voor meer informatie.

Markup-extensies

Markup-extensies zijn een XAML-taalconcept dat vaak wordt gebruikt in de Windows Runtime XAML-implementatie. Markeringsextensies vertegenwoordigen vaak een soort snelkoppeling waarmee een XAML-bestand toegang krijgt tot een waarde of gedrag dat niet alleen elementen declareert op basis van back-uptypen. Sommige markeringsextensies kunnen eigenschappen instellen met gewone tekenreeksen of met aanvullende geneste elementen, met als doel de syntaxis of de factoring tussen verschillende XAML-bestanden te stroomlijnen.

In de syntaxis van het XAML-kenmerk geven accolades {en} het gebruik van een XAML-markeringsextensie aan. Dit gebruik leidt de XAML-verwerking om te ontsnappen aan de algemene behandeling van kenmerkwaarden als een letterlijke tekenreeks of een rechtstreeks converteerbare tekenreekswaarde. In plaats daarvan roept een XAML-parser code aan die gedrag biedt voor die specifieke markeringsextensie en die code een alternatief object of gedrag oplevert dat de XAML-parser nodig heeft. Markeringsextensies kunnen argumenten hebben, die de naam van de markeringsextensie volgen en zich ook in de accolades bevinden. Normaal gesproken biedt een geëvalueerde opmaakextensie een objectretourwaarde. Tijdens het parseren wordt die retourwaarde ingevoegd in de positie in de objectstructuur waarin het gebruik van de markeringsextensie zich in de bron-XAML bevond.

Windows Runtime XAML ondersteunt deze opmaakextensies die zijn gedefinieerd onder de standaard XAML-naamruimte en worden begrepen door de Windows Runtime XAML-parser:

{x:Bind}: ondersteunt gegevensbinding, waardoor de evaluatie van eigenschappen wordt uitgesteld tot de runtime door speciale code uit te voeren, die tijdens het compileren wordt gegenereerd. Deze markeringsextensie ondersteunt een breed scala aan argumenten.
{Binding}: biedt ondersteuning voor gegevensbinding, waarmee de evaluatie van eigenschappen wordt uitgesteld tot de runtime, door middel van objectinspectie met een algemeen doel. Deze markeringsextensie ondersteunt een breed scala aan argumenten.
{StaticResource}: ondersteunt verwijzingen naar resourcewaarden die zijn gedefinieerd in een ResourceDictionary. Deze resources kunnen zich in een ander XAML-bestand bevinden, maar moeten uiteindelijk worden gevonden door de XAML-parser tijdens de laadtijd. Het argument van een {StaticResource} gebruiksvorm identificeert de sleutel (de naam) voor een gecodeerde resource in een ResourceDictionary.
{ThemeResource}: vergelijkbaar met {StaticResource} maar kan reageren op runtimethemawijzigingen. {ThemeResource} wordt vrij vaak weergegeven in de standaard XAML-sjablonen van Windows Runtime, omdat de meeste van deze sjablonen zijn ontworpen voor compatibiliteit met de gebruiker die het thema wijzigt terwijl de app wordt uitgevoerd.
{TemplateBinding}: een speciaal geval van {Binding} dat ondersteuning biedt voor beheersjablonen in XAML en het uiteindelijke gebruik ervan tijdens runtime.
{RelativeSource}: maakt een bepaalde vorm van sjabloonbinding mogelijk waarbij waarden afkomstig zijn van de bovenliggende sjabloon.
{CustomResource}: voor scenario's voor geavanceerde resource-opzoekingen.

Windows Runtime ondersteunt ook de markeringsextensie {x:Null}. U gebruikt dit om null-waarden in te stellen op null in XAML. U kunt dit bijvoorbeeld gebruiken in een besturingssjabloon voor een Selectievakje, waarmee null wordt geïnterpreteerd als een onbepaalde controlestatus (waarbij de visuele status 'Onbepaald' wordt geactiveerd).

Een markeringsextensie retourneert over het algemeen een bestaand exemplaar van een ander deel van de objectgrafiek voor de app of uitstelt een waarde voor runtime. Omdat u een markeringsextensie kunt gebruiken als een kenmerkwaarde en dat is het typische gebruik, ziet u vaak markeringsextensies die waarden bieden voor eigenschappen van het verwijzingstype die anders een syntaxis van een eigenschapselement hebben vereist.

Hier volgt bijvoorbeeld de syntaxis voor het verwijzen naar een herbruikbare stijl uit een ResourceDictionary: <Button Style="{StaticResource SearchButtonStyle}"/>. Een stijl is een verwijzingstype, geen eenvoudige waarde, dus zonder het {StaticResource} gebruik had u een <Button.Style> eigenschapselement en een <Style> definitie erin nodig om de eigenschap FrameworkElement.Style in te stellen.

Door markeringsextensies te gebruiken, is elke eigenschap die in XAML instelbaar is, mogelijk instelbaar in attribuutsyntaxis. U kunt kenmerksyntaxis gebruiken om referentiewaarden voor een eigenschap op te geven, zelfs als deze geen ondersteuning biedt voor een kenmerksyntaxis voor directe object-instantiëring. U kunt ook specifiek gedrag inschakelen waarmee de algemene vereiste wordt uitgesteld dat XAML-eigenschappen worden ingevuld door waardetypen of door nieuw gemaakte referentietypen.

Ter illustratie stelt het volgende XAML-voorbeeld de waarde van de eigenschap FrameworkElement.Style van een rand in met behulp van de syntaxis van het kenmerk. De FrameworkElement.Style eigenschap neemt een exemplaar van de klasse Stijl, een verwijzingstype dat standaard niet kon worden gemaakt met behulp van een tekenreeks voor kenmerksyntaxis. Maar in dit geval verwijst het kenmerk naar een bepaalde markeringsextensie, StaticResource. Wanneer deze markeringsextensie wordt verwerkt, wordt er een verwijzing geretourneerd naar een stijlelement dat eerder is gedefinieerd als een sleutelresource in een resourcewoordenlijst.

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

U kunt markup-extensies nesten. De binnenste markeringsextensie wordt eerst geëvalueerd.

Vanwege markeringsextensies hebt u speciale syntaxis nodig voor een letterlijke waarde {in een kenmerk. Zie de XAML-syntaxishandleiding voor meer informatie.

Evenementen

XAML is een declaratieve taal voor objecten en hun eigenschappen, maar bevat ook een syntaxis voor het koppelen van gebeurtenis-handlers aan objecten in de markeringen. De syntaxis van de XAML-gebeurtenis kan vervolgens de XAML-gedeclareerde gebeurtenissen integreren via het Windows Runtime-programmeermodel. U geeft de naam van de gebeurtenis op als een kenmerknaam voor het object waar de gebeurtenis wordt verwerkt. Voor de kenmerkwaarde geeft u de naam op van een gebeurtenis-handlerfunctie die u in code definieert. De XAML-processor gebruikt deze naam om een gedelegeerde weergave te maken in de geladen objectstructuur en voegt de opgegeven handler toe aan een interne handlerlijst. Bijna alle Windows Runtime-apps worden gedefinieerd door zowel markup als code-behind bestanden.

Hier volgt een eenvoudig voorbeeld. De knopklasse ondersteunt een gebeurtenis met de naam Click. U kunt een handler schrijven voor Klik waarmee code wordt uitgevoerd die moet worden aangeroepen nadat de gebruiker op de knop heeft geklikt. In XAML geeft u Klikken op als een kenmerk op de knop. Geef voor de kenmerkwaarde een tekenreeks op die de methodenaam van uw handler is.

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

Wanneer u compileert, verwacht de compiler nu dat er een methode showUpdatesButton_Click is die is gedefinieerd in het code-behind-bestand, in de naamruimte die is gedeclareerd in de x:Class-waarde van de XAML-pagina. Deze methode moet ook voldoen aan het gedelegeerde contract voor de Click-gebeurtenis. Voorbeeld:

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);
    };
}

Binnen een project wordt de XAML geschreven als een .xaml-bestand en gebruikt u de taal die u wilt gebruiken (C#, Visual Basic, C++/CX) om een code-behind-bestand te schrijven. Wanneer een XAML-bestand is gecompileerd als onderdeel van een buildactie voor het project, wordt de locatie van het XAML-codeachter-bestand voor elke XAML-pagina geïdentificeerd door een naamruimte en klasse op te geven als het kenmerk x:Class van het hoofdelement van de XAML-pagina. Zie het overzicht van gebeurtenissen en gerouteerde gebeurtenissen voor meer informatie over hoe deze mechanismen werken in XAML en hoe deze zich verhouden tot de programmeer- en toepassingsmodellen.

Opmerking

Voor C++/CX zijn er twee code-behind-bestanden: een is een header (.xaml.h) en de andere is implementatie (.xaml.cpp). De implementatie verwijst naar de header en het is technisch gezien de header die het toegangspunt voor de code-behind-verbinding vertegenwoordigt.

Resourcewoordenlijsten

Het maken van een ResourceDictionary is een algemene taak die meestal wordt uitgevoerd door een resourcewoordenlijst te ontwerpen als een gebied van een XAML-pagina of een afzonderlijk XAML-bestand. Resourcewoordenlijsten en hoe u deze kunt gebruiken, is een groter conceptueel gebied dat buiten het bereik van dit onderwerp valt. Zie ResourceDictionary- en XAML-resourceverwijzingen voor meer informatie.

XAML en XML

De XAML-taal is fundamenteel gebaseerd op de XML-taal. Maar XAML breidt XML aanzienlijk uit. In het bijzonder wordt het concept van schema anders benaderd vanwege de relatie met het onderliggende typeconcept, en worden taalelementen zoals gekoppelde leden en opmaakextensies toegevoegd. xml:lang is geldig in XAML, maar beïnvloedt runtime in plaats van parseringsgedrag, en wordt meestal gealiaseerd naar een eigenschap op frameworkniveau. Zie FrameworkElement.Language voor meer informatie. xml:base is geldig in markeringen, maar parsers negeren deze. xml:space is geldig, maar is alleen relevant voor scenario's die worden beschreven in het onderwerp XAML en witruimte . Het coderingskenmerk is geldig in XAML. Alleen UTF-8- en UTF-16-coderingen worden ondersteund. UTF-32-codering wordt niet ondersteund.

Hoofdlettergevoeligheid in XAML

XAML is hoofdlettergevoelig. Dit is een ander gevolg van het feit dat XAML wordt gebaseerd op XML, wat hoofdlettergevoelig is. De namen van XAML-elementen en -kenmerken zijn hoofdlettergevoelig. De waarde van een kenmerk is mogelijk hoofdlettergevoelig; dit is afhankelijk van hoe de kenmerkwaarde wordt verwerkt voor bepaalde eigenschappen. Als de kenmerkwaarde bijvoorbeeld de naam van een lid van een opsomming verklaart, is het ingebouwde gedrag dat een lidnaam als tekenreeks zou omzetten om de waarde van het opsommingslid te geven, niet hoofdlettergevoelig. In tegenstelling daarmee behandelen de waarde van de eigenschap Naam en de hulpmethoden voor het werken met objecten op basis van de naam die de eigenschap Naam declareert, de naamtekenreeks als hoofdlettergevoelig.

XAML-naamscopen

De XAML-taal definieert een concept van een XAML-naamscoop. Het XAML-naamscoopconcept beïnvloedt hoe XAML-processors de waarde van x:Name of Name moeten behandelen die zijn toegepast op XAML-elementen, met name de bereiken waarin namen moeten worden vertrouwd om unieke id's te zijn. XAML-naamscopen worden uitvoeriger behandeld in een afzonderlijk onderwerp; zie XAML-naamscopen.

De rol van XAML in het ontwikkelingsproces

XAML speelt verschillende belangrijke rollen in het ontwikkelingsproces voor apps.

XAML is de primaire indeling voor het declareren van de gebruikersinterface en elementen van een app in die gebruikersinterface, als u programmeert met C#, Visual Basic of C++/CX. Normaal gesproken vertegenwoordigt ten minste één XAML-bestand in uw project een pagina-metafoor in uw app voor de in eerste instantie weergegeven gebruikersinterface. Extra XAML-bestanden kunnen extra pagina's declareren voor de navigatie-UI. Andere XAML-bestanden kunnen resources declareren, zoals sjablonen of stijlen.
U gebruikt de XAML-indeling voor het declareren van stijlen en sjablonen die zijn toegepast op besturingselementen en gebruikersinterfaces voor een app.
U kunt stijlen en sjablonen gebruiken om bestaande besturingselementen te templeren of als u een besturingselement definieert dat een standaardsjabloon levert als onderdeel van een besturingspakket. Wanneer u deze gebruikt om stijlen en sjablonen te definiëren, wordt de relevante XAML vaak gedeclareerd als een discreet XAML-bestand met een ResourceDictionary-hoofdmap .
XAML is de algemene indeling voor ontwerpfunctieondersteuning voor het maken van de gebruikersinterface van apps en het uitwisselen van het UI-ontwerp tussen verschillende ontwerp-apps. Met name XAML voor de app kan worden uitgewisseld tussen verschillende XAML-ontwerpprogramma's (of ontwerpvensters binnen hulpprogramma's).
Verschillende andere technologieën definiëren ook de basisgebruikersinterface in XAML. In relatie tot Windows Presentation Foundation (WPF) XAML en Microsoft Silverlight XAML gebruikt de XAML voor Windows Runtime dezelfde URI voor de gedeelde XAML-naamruimte. De XAML-woordenlijst voor Windows Runtime overlapt aanzienlijk met de XAML-for-UI-woordenlijst die ook wordt gebruikt door Silverlight en in iets mindere mate door WPF. XAML bevordert dus een efficiënt migratiepad voor de gebruikersinterface die oorspronkelijk is gedefinieerd voor voorlopertechnologieën die ook gebruikmaken van XAML.
XAML definieert het uiterlijk van een gebruikersinterface en een gekoppeld code-behind-bestand definieert de logica. U kunt het ontwerp van de gebruikersinterface aanpassen zonder wijzigingen aan te brengen in de logica in codeachter. XAML vereenvoudigt de werkstroom tussen ontwerpers en ontwikkelaars.
Vanwege de rijkdom van de visuele ontwerper en ontwerpoppervlakondersteuning voor de XAML-taal ondersteunt XAML snelle ui-prototypen in de vroege ontwikkelingsfasen.

Afhankelijk van uw eigen rol in het ontwikkelingsproces, werkt u mogelijk niet veel met XAML. De mate waarin u met XAML-bestanden werkt, is ook afhankelijk van de ontwikkelomgeving die u gebruikt, of u interactieve ontwerpomgevingsfuncties gebruikt, zoals werksets en eigenschappeneditors, en het bereik en doel van uw Windows Runtime-app. Toch is het waarschijnlijk dat u tijdens de ontwikkeling van de app een XAML-bestand op elementniveau gaat bewerken met behulp van een tekst- of XML-editor. Met deze informatie kunt u XAML in een tekst- of XML-weergave bewerken en de geldigheid van de declaraties en het doel van dat XAML-bestand behouden wanneer het wordt gebruikt door hulpprogramma's, compileerbewerkingen voor markeringen of de runtimefase van uw Windows Runtime-app.

Uw XAML optimaliseren voor belastingprestaties

Hier volgen enkele tips voor het definiëren van UI-elementen in XAML met aanbevolen procedures voor prestaties. Veel van deze tips hebben betrekking op het gebruik van XAML-resources, maar worden hier vermeld in het algemene XAML-overzicht voor het gemak. Zie ResourceDictionary- en XAML-resourceverwijzingen voor meer informatie over XAML-resources. Voor meer tips over prestaties, inclusief voorbeelden van XAML die bewust enkele slechte prestatiepraktijken demonstreren die u in uw XAML moet vermijden, zie Uw XAML-opmaak optimaliseren.

Als u dezelfde kleurborstel vaak gebruikt in uw XAML, definieert u een SolidColorBrush als een resource in plaats van elke keer een benoemde kleur te gebruiken als een kenmerkwaarde.
Als u dezelfde resource op meer dan één ui-pagina gebruikt, kunt u overwegen deze te definiëren in Application.Resources in plaats van op elke pagina. Als slechts één pagina gebruikmaakt van een resource, definieert u deze echter niet in Application.Resources en definieert u deze alleen voor de pagina die deze nodig heeft. Dit is zowel geschikt voor XAML-factoring tijdens het ontwerpen van uw app als voor prestaties tijdens het parseren van XAML.
Voor resources die uw app-pakketten gebruiken, controleert u op ongebruikte resources (een resource met een sleutel, maar er is geen StaticResource-verwijzing in uw app die deze gebruikt). Verwijder deze uit uw XAML voordat u uw app loslaat.
Als u afzonderlijke XAML-bestanden gebruikt die ontwerpresources (MergedDictionaries) bieden, kunt u overwegen ongebruikte resources uit deze bestanden te commentaar te geven of te verwijderen. Zelfs als u een gedeeld XAML-startpunt hebt dat u in meer dan één app gebruikt of die algemene resources biedt voor al uw apps, is het nog steeds uw app die de XAML-resources elke keer verpakt en mogelijk moet laden.
Definieer geen UI-elementen die u niet nodig hebt voor samenstelling en gebruik waar mogelijk de standaardbeheersjablonen (deze sjablonen zijn al getest en geverifieerd voor belastingprestaties).
Gebruik containers zoals Rand in plaats van opzettelijke overtekeningen van UI-elementen. Teken in principe niet meerdere keren dezelfde pixel. Zie voor meer informatie over overdraw en hoe dit te testen DebugSettings.IsOverdrawHeatMapEnabled.
Gebruik de standaarditemssjablonen voor ListView of GridView; deze hebben speciale presentatorlogica waarmee prestatieproblemen worden opgelost bij het bouwen van de visualstructuur voor grote aantallen lijstitems.

Fouten opsporen in XAML

Omdat XAML een opmaaktaal is, zijn sommige van de typische strategieën voor foutopsporing in Microsoft Visual Studio niet beschikbaar. Er is bijvoorbeeld geen manier om een onderbrekingspunt in te stellen in een XAML-bestand. Er zijn echter andere technieken waarmee u problemen met UI-definities of andere XAML-markeringen kunt opsporen terwijl u uw app nog ontwikkelt.

Wanneer er problemen zijn met een XAML-bestand, is het meest voorkomende resultaat dat een systeem of uw app een XAML-parseringsuitzondering genereert. Wanneer er een XAML-parseringsuitzondering is, kan de XAML die door de XAML-parser wordt geladen, geen geldige objectstructuur maken. In sommige gevallen, bijvoorbeeld wanneer de XAML de eerste pagina van uw toepassing vertegenwoordigt die is geladen als de hoofdvisual, kan de XAML-parseringsuitzondering niet worden hersteld.

XAML wordt vaak bewerkt binnen een IDE, zoals Visual Studio en een van de XAML-ontwerpoppervlakken. Visual Studio kan vaak ontwerptijdvalidatie en foutcontrole van een XAML-bron bieden terwijl u deze bewerkt. Er kunnen bijvoorbeeld 'kronkels' zichtbaar worden in de XAML-teksteditor zodra u een ongeldige kenmerkwaarde typt, en u hoeft niet eens te wachten op een XAML-compileerbewerking om te zien dat er iets mis is met uw UI-definitie.

Zodra de app daadwerkelijk wordt uitgevoerd, en er zijn XAML-parseringsfouten die tijdens de ontwerpfase onopgemerkt zijn gebleven, worden deze door de Common Language Runtime (CLR) gerapporteerd als een XamlParseException. Zie Uitzonderingsafhandeling voor Windows Runtime-apps in C# of Visual Basic voor meer informatie over wat u kunt doen voor een runtime XamlParseException.