Übersicht über XAML

Artikel
07/04/2024

In diesem Artikel werden die XAML-Sprach- und XAML-Konzepte der Windows-Runtime App-Entwicklergruppe vorgestellt und die verschiedenen Methoden zum Deklarieren von Objekten und Festlegen von Attributen in XAML beschrieben, da sie zum Erstellen einer Windows-Runtime-App verwendet wird.

Was ist XAML?

Extensible Application Markup Language (XAML) ist eine deklarative Sprache. Insbesondere kann XAML Objekte initialisieren und Eigenschaften von Objekten mithilfe einer Sprachstruktur festlegen, die hierarchische Beziehungen zwischen mehreren Objekten und einer Sicherungstypkonvention anzeigt, die Erweiterung von Typen unterstützt. Sie können sichtbare UI-Elemente im deklarativen XAML-Markup erstellen. Anschließend können Sie eine separate CodeBehind-Datei für jede XAML-Datei zuordnen, die auf Ereignisse reagieren und die Objekte bearbeiten kann, die Sie ursprünglich in XAML deklarieren.

Die XAML-Sprache unterstützt den Austausch von Quellen zwischen verschiedenen Tools und Rollen im Entwicklungsprozess, z. B. den Austausch von XAML-Quellen zwischen Entwurfstools und einer interaktiven Entwicklungsumgebung (IDE) oder zwischen primären Entwicklern und Lokalisierungsentwicklern. Durch die Verwendung von XAML als Austauschformat können Designerrollen und Entwicklerrollen getrennt oder zusammengeführt werden, und Designer und Entwickler können während der Produktion einer App durchlaufen.

Wenn Sie sie als Teil Ihrer Windows-Runtime-App-Projekte sehen, sind XAML-Dateien XML-Dateien mit der Dateinamenerweiterung .xaml.

Grundlegende XAML-Syntax

XAML verfügt über eine grundlegende Syntax, die auf XML basiert. Standardmäßig muss gültiges XAML auch gültiges XML sein. XAML verfügt jedoch auch über Syntaxkonzepte, die einer anderen und vollständigeren Bedeutung zugewiesen werden, während sie weiterhin in XML pro XML 1.0-Spezifikation gültig sind. Xaml unterstützt beispielsweise die Eigenschaftselementsyntax, bei der Eigenschaftswerte innerhalb von Elementen und nicht als Zeichenfolgenwerte in Attributen oder als Inhalt festgelegt werden können. Bei regulärem XML ist ein XAML-Eigenschaftselement ein Element mit einem Punkt im Namen, sodass es für einfache XML gültig ist, aber nicht die gleiche Bedeutung hat.

XAML und Visual Studio

Microsoft Visual Studio hilft Ihnen, gültige XAML-Syntax sowohl im XAML-Text-Editor als auch in der grafischeren XAML-Entwurfsoberfläche zu erstellen. Wenn Sie XAML für Ihre App mit Visual Studio schreiben, machen Sie sich bei jedem Tastenanschlag nicht zu viele Gedanken über die Syntax. Die IDE ermutigt eine gültige XAML-Syntax, indem Sie AutoVervollständigen-Hinweise bereitstellen, Vorschläge in Microsoft IntelliSense-Listen und -Dropdowns anzeigen, UI-Elementbibliotheken im Toolboxfenster oder andere Techniken anzeigen. Wenn Dies Ihre erste Erfahrung mit XAML ist, kann es dennoch hilfreich sein, die Syntaxregeln und insbesondere die Terminologie zu kennen, die manchmal verwendet wird, um die Einschränkungen oder Auswahlmöglichkeiten beim Beschreiben der XAML-Syntax in Referenz oder anderen Themen zu beschreiben. Die fine points of XAML syntax are covered in a separate topic, XAML syntax guide.

XAML-Namespaces

In der allgemeinen Programmierung ist ein Namespace ein Organisationskonzept, das bestimmt, wie Bezeichner für Programmierentitäten interpretiert werden. Mithilfe von Namespaces kann ein Programmierframework benutzerdefinierte Bezeichner von vom Framework deklarierten Bezeichnern trennen, mehrdeutige Bezeichner durch Namespacequalifikationen disambiguieren, Regeln für die Bereichsdefinition von Namen erzwingen usw. XAML verfügt über ein eigenes XAML-Namespacekonzept, das diesem Zweck für die XAML-Sprache dient. Hier erfahren Sie, wie XAML die XML-Sprachnamespacekonzepte anwendet und erweitert:

XAML verwendet die reservierten XML-Attribut-XML-Xmlns für Namespacedeklarationen. Der Wert des Attributs ist in der Regel ein Uniform Resource Identifier (URI), bei dem es sich um eine Konvention handelt, die von XML geerbt wird.
XAML verwendet Präfixe in Deklarationen, um nicht standardmäßige Namespaces zu deklarieren, und Präfixverwendungen in Elementen und Attributen verweisen auf diesen Namespace.
XAML verfügt über ein Konzept eines Standardnamespaces, der als Namespace verwendet wird, wenn in einer Verwendung oder Deklaration kein Präfix vorhanden ist. Der Standardnamespace kann für jedes XAML-Programmierframework unterschiedlich definiert werden.
Namespacedefinitionen erben in einer XAML-Datei oder einem Konstrukt von übergeordnetem Element zu untergeordnetem Element. Wenn Sie beispielsweise einen Namespace im Stammelement einer XAML-Datei definieren, erben alle Elemente innerhalb dieser Datei diese Namespacedefinition. Wenn ein Element weiter in der Seite den Namespace neu definiert, erben die Nachfolger dieses Elements die neue Definition.
Attribute eines Elements erben die Namespaces des Elements. Es ist ziemlich ungewöhnlich, Präfixe für XAML-Attribute zu sehen.

Eine XAML-Datei deklariert fast immer einen standardmäßigen XAML-Namespace im Stammelement. Der standardmäßige XAML-Namespace definiert, welche Elemente Sie deklarieren können, ohne sie durch ein Präfix zu qualifizieren. Für typische Windows-Runtime-App-Projekte enthält dieser Standardnamespace alle integrierten XAML-Vokabular für die Windows-Runtime, die für UI-Definitionen verwendet werden: die Standardsteuerelemente, Textelemente, XAML-Grafiken und Animationen, Datenbindungs- und Formatierungsunterstützungstypen usw. Die meisten XAML-Code, den Sie für Windows-Runtime Apps schreiben, können daher die Verwendung von XAML-Namespaces und Präfixen vermeiden, wenn Sie auf allgemeine UI-Elemente verweisen.

Hier ist ein Codeausschnitt, der einen vom Vorlagen erstellten Page Stamm der Startseite für eine App anzeigt (nur das öffnende Tag und vereinfacht). Er deklariert den Standardnamespace und auch den x-Namespace (den wir als nächstes erläutern).

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

Der XAML-Sprach-XAML-Namespace

Ein bestimmter XAML-Namespace, der in fast jeder Windows-Runtime XAML-Datei deklariert wird, ist der XAML-Sprachnamespace. Dieser Namespace enthält Elemente und Konzepte, die von der XAML-Sprachspezifikation definiert werden. Standardmäßig wird der XAML-Sprach-XAML-Namespace dem Präfix "x" zugeordnet. Die Standardprojekt- und Dateivorlagen für Windows-Runtime-App-Projekte definieren immer sowohl den standardmäßigen XAML-Namespace (kein Präfix, nurxmlns=) als auch den XAML-Sprach-XAML-Namespace (Präfix "x") als Teil des Stammelements.

Der XAML-Namespace "x" (Präfix/XAML-Sprache) enthält mehrere Programmierkonstrukte, die Sie häufig in Xaml verwenden. Die häufigsten lauten:

Begriff	Beschreibung
x:Key	Legt einen eindeutigen benutzerdefinierten Schlüssel für jede Ressource in einem XAML-Code ResourceDictionaryfest. Die Tokenzeichenfolge des Schlüssels ist das Argument für die StaticResource-Markuperweiterung , und Sie verwenden diesen Schlüssel später, um die XAML-Ressource aus einer anderen XAML-Verwendung an anderer Stelle im XAML-Code Ihrer App abzurufen.
x:Class	Gibt den Codenamespace und den Codeklassennamen für die Klasse an, die CodeBehind für eine XAML-Seite bereitstellt. Dies benennt die Klasse, die beim Erstellen ihrer App von den Buildaktionen erstellt oder verknüpft wird. Diese Buildaktionen unterstützen den XAML-Markupcompiler und kombinieren Ihr Markup und CodeBehind, wenn die App kompiliert wird. Sie müssen über eine solche Klasse verfügen, um CodeBehind für eine XAML-Seite zu unterstützen. Window.Contentim Standardaktivierungsmodell Windows-Runtime.
x:Name	Gibt einen Laufzeitobjektnamen für die Instanz an, die im Laufzeitcode vorhanden ist, nachdem ein in XAML definiertes Objektelement verarbeitet wurde. Sie können sich das Festlegen von "x:Name " in XAML wie das Deklarieren einer benannten Variablen im Code vorstellen. Wie Sie später erfahren werden, geschieht das genau, wenn Ihr XAML als Komponente einer Windows-Runtime-App geladen wird. Hinweis Name ist eine ähnliche Eigenschaft im Framework, aber nicht alle Elemente unterstützen sie. Verwenden Sie "x:Name " für die Elementidentifikation, wenn FrameworkElement.Name für diesen Elementtyp nicht unterstützt wird.
x:Uid	Identifiziert Elemente, die lokalisierte Ressourcen für einige ihrer Eigenschaftswerte verwenden sollen. Weitere Informationen zur Verwendung von x:Uid finden Sie in der Schnellstartanleitung: Übersetzen von UI-Ressourcen.
Systeminterne XAML-Datentypen	Diese Typen können Werte für einfache Werttypen angeben, wenn dies für ein Attribut oder eine Ressource erforderlich ist. Diese systeminternen Typen entsprechen den einfachen Werttypen, die in der Regel als Teil der systeminternen Definitionen jeder Programmiersprache definiert sind. Beispielsweise benötigen Sie möglicherweise ein Objekt, das einen echten booleschen Wert darstellt, der in einem ObjectAnimationUsingKeyFrames storyboardierten visuellen Zustand verwendet werden soll. Für diesen Wert in XAML verwenden Sie den systeminternen x:Boolean-Typ wie das Objektelement: `<x:Boolean>True</x:Boolean>`

Andere Programmierkonstrukte im XAML-Sprach-XAML-Namespace sind vorhanden, sind jedoch nicht so häufig.

Zuordnen benutzerdefinierter Typen zu XAML-Namespaces

Einer der leistungsstärksten Aspekte von XAML als Sprache ist, dass es einfach ist, das XAML-Vokabular für Ihre Windows-Runtime-Apps zu erweitern. Sie können ihre eigenen benutzerdefinierten Typen in der Programmiersprache Ihrer App definieren und dann im XAML-Markup auf Ihre benutzerdefinierten Typen verweisen. Die Unterstützung für die Erweiterung über benutzerdefinierte Typen ist grundlegend integriert, um die Funktionsweise der XAML-Sprache zu unterstützen. Frameworks oder App-Entwickler sind für das Erstellen der Sicherungsobjekte verantwortlich, auf die XAML verweist. Weder Frameworks noch der App-Entwickler sind an Spezifikationen gebunden, was die Objekte in ihren Vokabularn darstellen oder über die grundlegenden XAML-Syntaxregeln hinausgehen. (Es gibt einige Erwartungen, was die XAML-Sprach-XAML-Namespacetypen tun sollten, aber die Windows-Runtime bietet alle erforderlichen Unterstützung.)

Wenn Sie XAML für Typen verwenden, die aus anderen Bibliotheken als den Windows-Runtime Kernbibliotheken und Metadaten stammen, müssen Sie einen XAML-Namespace mit einem Präfix deklarieren und zuordnen. Verwenden Sie dieses Präfix in Elementverwendungen, um auf die Typen zu verweisen, die in Ihrer Bibliothek definiert wurden. Sie deklarieren Präfixzuordnungen als XMLns-Attribute , in der Regel in einem Stammelement zusammen mit den anderen XAML-Namespacedefinitionen.

Wenn Sie eine eigene Namespacedefinition erstellen möchten, die auf benutzerdefinierte Typen verweist, geben Sie zuerst das Schlüsselwort "xmlns:" und dann das gewünschte Präfix an. Der Wert dieses Attributs muss das Schlüsselwort enthalten, das folgendes verwendet: als erster Teil des Werts. Der rest des Werts ist ein Zeichenfolgentoken, das auf den spezifischen Codesicherungsnamespace verweist, der Ihre benutzerdefinierten Typen enthält, anhand des Namens.

Das Präfix definiert das Markuptoken, das verwendet wird, um auf diesen XAML-Namespace im rest des Markups in dieser XAML-Datei zu verweisen. Ein Doppelpunktzeichen (:) zwischen dem Präfix und der Entität, auf die innerhalb des XAML-Namespace verwiesen werden soll.

Die Attributsyntax zum Zuordnen eines Präfixes myTypes zum Namespace myCompany.myTypes lautet beispielsweise: xmlns:myTypes="using:myCompany.myTypes", und eine repräsentative Elementverwendung lautet: <myTypes:CustomButton/>

Weitere Informationen zum Zuordnen von XAML-Namespaces für benutzerdefinierte Typen, einschließlich besonderer Überlegungen für Visual C++-Komponentenerweiterungen (C++/CX), finden Sie unter XAML-Namespaces und Namespacezuordnung.

Andere XAML-Namespaces

Häufig werden XAML-Dateien angezeigt, die die Präfixe "d" (für den Designernamespace) und "mc" (zur Markupkompatibilität) definieren. Im Allgemeinen dienen diese zur Infrastrukturunterstützung oder zum Aktivieren von Szenarien in einem Entwurfszeittool. Weitere Informationen finden Sie im Abschnitt "Andere XAML-Namespaces" des Themas "XAML-Namespaces".

Markuperweiterungen

Markuperweiterungen sind ein XAML-Sprachkonzept, das häufig in der Windows-Runtime XAML-Implementierung verwendet wird. Markuperweiterungen stellen häufig eine Art von "Verknüpfung" dar, die es einer XAML-Datei ermöglicht, auf einen Wert oder ein Verhalten zuzugreifen, das nicht einfach Elemente basierend auf Sicherungstypen deklariert. Einige Markuperweiterungen können Eigenschaften mit einfachen Zeichenfolgen oder mit zusätzlich geschachtelten Elementen festlegen, mit dem Ziel, die Syntax oder den Faktor zwischen verschiedenen XAML-Dateien zu optimieren.

In der XAML-Attributsyntax geben geschweifte Klammern "{" und "}" eine Verwendung der XAML-Markuperweiterung an. Diese Verwendung leitet die XAML-Verarbeitung an, um die allgemeine Behandlung von Attributwerten als Literalzeichenfolge oder einen direkten Zeichenfolgen-Konvertierbar-Wert zu umgehen. Stattdessen ruft ein XAML-Parser Code auf, der Verhalten für diese bestimmte Markuperweiterung bereitstellt und dieser Code ein alternatives Objekt oder Verhalten ergebnis bereitstellt, das der XAML-Parser benötigt. Markuperweiterungen können Argumente aufweisen, die dem Namen der Markuperweiterung folgen und auch in den geschweiften geschweiften Klammern enthalten sind. In der Regel stellt eine ausgewertete Markuperweiterung einen Objektrückgabewert bereit. Während der Analyse wird dieser Rückgabewert in die Position in der Objektstruktur eingefügt, an der sich die Verwendung der Markuperweiterung im Quell-XAML befand.

Windows-Runtime XAML unterstützt diese Markuperweiterungen, die unter dem standardmäßigen XAML-Namespace definiert sind und vom Windows-Runtime XAML-Parser verstanden werden:

{x:Bind}: unterstützt die Datenbindung, die die Eigenschaftenauswertung bis zur Laufzeit zurückstellt, indem sie speziellen Code ausführt, der zur Kompilierungszeit generiert wird. Diese Markuperweiterung unterstützt eine breite Palette von Argumenten.
{Binding}: unterstützt die Datenbindung, die die Eigenschaftenauswertung bis zur Laufzeit zurückgibt, indem eine allgemeine Laufzeitobjektüberprüfung ausgeführt wird. Diese Markuperweiterung unterstützt eine breite Palette von Argumenten.
{StaticResource}: unterstützt das Verweisen auf Ressourcenwerte, die in einer ResourceDictionary. Diese Ressourcen können sich in einer anderen XAML-Datei befinden, müssen aber letztendlich vom XAML-Parser zum Ladezeitpunkt gefunden werden. Das Argument einer {StaticResource} Verwendung identifiziert den Schlüssel (den Namen) für eine Schlüsselressource in einer ResourceDictionary.
{ThemeResource}: ähnlich wie {StaticResource} , kann aber auf Änderungen des Laufzeitdesigns reagieren. {ThemeResource} wird häufig in den Windows-Runtime Standard-XAML-Vorlagen angezeigt, da die meisten dieser Vorlagen auf Kompatibilität mit dem Benutzer ausgelegt sind, der das Design wechselt, während die App ausgeführt wird.
{TemplateBinding}: ein Sonderfall von {Binding}, der Steuerelementvorlagen in XAML und deren spätere Verwendung zur Laufzeit unterstützt.
{RelativeSource}: Ermöglicht eine bestimmte Form der Vorlagenbindung, bei der Werte aus dem übergeordneten Vorlagenobjekt stammen.
{CustomResource}: für erweiterte Ressourcensuchszenarien.

Windows-Runtime unterstützt auch die {x:Null}-Markuperweiterung. Verwenden Sie diese Einstellung, um Nullwerte in XAML auf Null festzulegen. Sie können dies z. B. in einer Steuerelementvorlage für ein CheckBoxSteuerelement verwenden, das null als unbestimmten Prüfzustand interpretiert (das Auslösen des visuellen Zustands "Unbestimmt").

Eine Markuperweiterung gibt in der Regel eine vorhandene Instanz aus einem anderen Teil des Objektdiagramms für die App zurück oder verschärft einen Wert zur Laufzeit. Da Sie eine Markuperweiterung als Attributwert verwenden können und dies die typische Verwendung ist, sehen Sie häufig Markuperweiterungen, die Werte für Referenztypeigenschaften bereitstellen, die andernfalls eine Eigenschaftselementsyntax benötigt haben.

Dies ist z. B. die Syntax zum Verweisen auf ein wiederverwendbares Style Aus einem ResourceDictionary: <Button Style="{StaticResource SearchButtonStyle}"/>. A Style ist ein Bezugstyp, kein einfacher Wert, sodass Sie ohne die {StaticResource} Verwendung ein <Button.Style> Eigenschaftselement und eine <Style> Definition benötigt hätten, um die FrameworkElement.Style Eigenschaft festzulegen.

Durch die Verwendung von Markuperweiterungen kann jede eigenschaft, die in XAML festgelegt wird, in der Attributsyntax potenziell festgelegt werden. Mithilfe der Attributsyntax können Sie Referenzwerte für eine Eigenschaft bereitstellen, auch wenn sie andernfalls keine Attributsyntax für die direkte Objektinstanziierung unterstützt. Sie können auch ein bestimmtes Verhalten aktivieren, das die allgemeine Anforderung zurücksetzt, dass XAML-Eigenschaften von Werttypen oder von neu erstellten Verweistypen gefüllt werden.

Zur Veranschaulichung legt das nächste XAML-Beispiel den Wert der FrameworkElement.Style Eigenschaft einer Border mithilfe der Attributsyntax fest. Die FrameworkElement.Style Eigenschaft verwendet eine Instanz der Klasse, einen Verweistyp, der Windows.UI.Xaml.Style standardmäßig nicht mithilfe einer Attributsyntaxzeichenfolge erstellt werden konnte. In diesem Fall verweist das Attribut jedoch auf eine bestimmte Markuperweiterung, StaticResource. Wenn diese Markuperweiterung verarbeitet wird, wird ein Verweis auf ein Style-Element zurückgegeben, das zuvor als Schlüsselressource in einem Ressourcenwörterbuch definiert wurde.

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

Sie können Markuperweiterungen schachteln. Die innerste Markuperweiterung wird zuerst ausgewertet.

Aufgrund von Markuperweiterungen benötigen Sie eine spezielle Syntax für einen Literalwert "{" in einem Attribut. Weitere Informationen finden Sie in der XAML-Syntaxanleitung.

Ereignisse

XAML ist eine deklarative Sprache für Objekte und deren Eigenschaften, enthält aber auch eine Syntax zum Anfügen von Ereignishandlern an Objekte im Markup. Die XAML-Ereignissyntax kann dann die XAML-deklarierten Ereignisse über das Windows-Runtime Programmiermodell integrieren. Sie geben den Namen des Ereignisses als Attributnamen für das Objekt an, in dem das Ereignis behandelt wird. Für den Attributwert geben Sie den Namen einer Ereignishandlerfunktion an, die Sie im Code definieren. Der XAML-Prozessor verwendet diesen Namen, um eine Delegatendarstellung in der geladenen Objektstruktur zu erstellen, und fügt den angegebenen Handler zu einer internen Handlerliste hinzu. Fast alle Windows-Runtime Apps werden sowohl durch Markup- als auch durch CodeBehind-Quellen definiert.

Dies ist ein einfaches Beispiel. Die Button Klasse unterstützt ein Ereignis mit dem Namen Click. Sie können einen Handler für Click schreiben, der Code ausführt, der aufgerufen werden soll, nachdem der Benutzer auf die Schaltfläche geklickt hat. In XAML geben Sie Click als Attribut für die Schaltfläche an. Geben Sie für den Attributwert eine Zeichenfolge an, die den Methodennamen des Handlers darstellt.

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

Beim Kompilieren erwartet der Compiler nun, dass eine In der CodeBehind-Datei definierte Methode showUpdatesButton_Click im Namespace vorhanden ist, der im x:Class-Wert der XAML-Seite deklariert ist. Außerdem muss diese Methode den Delegatvertrag für das Click Ereignis erfüllen. Zum Beispiel:

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

Innerhalb eines Projekts wird der XAML-Code als XAML-Datei geschrieben, und Sie verwenden die bevorzugte Sprache (C#, Visual Basic, C++/CX), um eine CodeBehind-Datei zu schreiben. Wenn eine XAML-Datei als Teil einer Buildaktion für das Projekt markupkompiliert wird, wird der Speicherort der XAML-CodeBehind-Datei für jede XAML-Seite durch Angeben eines Namespaces und einer Klasse als x:Class-Attribut des Stammelements der XAML-Seite identifiziert. Weitere Informationen dazu, wie diese Mechanismen in XAML funktionieren und wie sie sich auf die Programmierungs- und Anwendungsmodelle beziehen, finden Sie unter "Ereignisse und Routingereignisse" (Übersicht).

Hinweis

Für C++/CX gibt es zwei CodeBehind-Dateien: eine ist ein Header (.xaml.h) und die andere Implementierung (.xaml.cpp). Die Implementierung verweist auf den Header, und es handelt sich technisch um den Header, der den Einstiegspunkt für die CodeBehind-Verbindung darstellt.

Ressourcenverzeichnisse

Das Erstellen einer ResourceDictionary Datei ist eine häufige Aufgabe, die in der Regel durch erstellen eines Ressourcenwörterbuchs als Bereich einer XAML-Seite oder einer separaten XAML-Datei erreicht wird. Ressourcenwörterbücher und deren Verwendung sind ein größerer konzeptioneller Bereich, der sich außerhalb des Bereichs dieses Themas befindet. Weitere Informationen finden Sie unter ResourceDictionary- und XAML-Ressourcenverweise.

XAML und XML

Die XAML-Sprache basiert grundsätzlich auf der XML-Sprache. XAML erweitert XML jedoch erheblich. Insbesondere behandelt es das Konzept des Schemas aufgrund seiner Beziehung zum Sicherungstypkonzept ganz anders und fügt Sprachelemente wie angefügte Member und Markuperweiterungen hinzu. "xml:lang " ist in XAML gültig, beeinflusst jedoch das Laufzeitverhalten und wird in der Regel als Alias für eine Eigenschaft auf Frameworkebene verwendet. Weitere Informationen finden Sie unter FrameworkElement.Language. xml:base ist im Markup gültig, aber Parser ignorieren sie. "xml:space " ist gültig, ist aber nur für Szenarien relevant, die im Thema XAML und Leerzeichen beschrieben werden. Das Codierungsattribut ist in XAML gültig. Nur UTF-8- und UTF-16-Codierungen werden unterstützt. UTF-32-Codierung wird nicht unterstützt.

Groß-/Kleinschreibung in XAML

BEI XAML wird die Groß-/Kleinschreibung beachtet. Dies ist eine weitere Folge von XAML, die auf XML basiert, bei dem die Groß-/Kleinschreibung beachtet wird. Bei den Namen von XAML-Elementen und -Attributen wird die Groß-/Kleinschreibung beachtet. Bei dem Wert eines Attributs wird die Groß-/Kleinschreibung möglicherweise beachtet. Dies hängt davon ab, wie der Attributwert für bestimmte Eigenschaften behandelt wird. Wenn der Attributwert z. B. einen Membernamen einer Enumeration deklariert, wird bei dem integrierten Verhalten, das eine Elementnamenzeichenfolge typkonvertiert, um den Enumerationsmememerwert zurückzugeben, die Groß-/Kleinschreibung nicht beachtet. Im Gegensatz dazu behandeln der Wert der Name-Eigenschaft und Hilfsmethoden für das Arbeiten mit Objekten basierend auf dem Namen, den die Name-Eigenschaft deklariert, die Namenszeichenfolge als Groß-/Kleinschreibung.

XAML-Namescopes

Die XAML-Sprache definiert ein Konzept eines XAML-NameScopes. Das XAML-NameScope-Konzept beeinflusst, wie XAML-Prozessoren den Wert von x:Name oder Name behandeln sollten, der auf XAML-Elemente angewendet wird, insbesondere die Bereiche, in denen Namen als eindeutige Bezeichner verwendet werden sollen. XAML-NameScopes werden in einem separaten Thema ausführlicher behandelt. siehe XAML-NameScopes.

Die Rolle von XAML im Entwicklungsprozess

XAML spielt im App-Entwicklungsprozess mehrere wichtige Rollen.

XAML ist das primäre Format zum Deklarieren der Ui und Elemente einer App in dieser Benutzeroberfläche, wenn Sie mit C#, Visual Basic oder C++/CX programmieren. In der Regel stellt mindestens eine XAML-Datei in Ihrem Projekt eine Seitenmetapher in Ihrer App für die anfänglich angezeigte Benutzeroberfläche dar. Zusätzliche XAML-Dateien deklarieren möglicherweise zusätzliche Seiten für die Navigationsbenutzeroberfläche. Andere XAML-Dateien können Ressourcen deklarieren, z. B. Vorlagen oder Stile.
Sie verwenden das XAML-Format zum Deklarieren von Stilen und Vorlagen, die auf Steuerelemente und UI für eine App angewendet werden.
Sie können Formatvorlagen und Vorlagen entweder für vorlagen vorhandene Steuerelemente verwenden oder wenn Sie ein Steuerelement definieren, das eine Standardvorlage als Teil eines Steuerelementpakets bereitstellt. Wenn Sie es zum Definieren von Stilen und Vorlagen verwenden, wird der relevante XAML-Code häufig als separate XAML-Datei mit einem ResourceDictionary Stamm deklariert.
XAML ist das gängige Format für die Designerunterstützung beim Erstellen der App-UI und beim Austausch des UI-Designs zwischen verschiedenen Designer-Apps. Insbesondere kann XAML für die App zwischen verschiedenen XAML-Designtools (oder Entwurfsfenstern innerhalb von Tools) ausgetauscht werden.
Mehrere andere Technologien definieren auch die grundlegende Benutzeroberfläche in XAML. In Beziehung zu Windows Presentation Foundation (WPF)-XAML und Microsoft Silverlight-XAML verwendet der XAML-Code für Windows-Runtime denselben URI für den freigegebenen Standard-XAML-Namespace. Das XAML-Vokabular für Windows-Runtime überlappt erheblich mit dem xaml-for-UI-Vokabular, das auch von Silverlight und in einem etwas geringeren Umfang von WPF verwendet wird. Daher fördert XAML einen effizienten Migrationspfad für die Benutzeroberfläche, die ursprünglich für Vorläufertechnologien definiert wurde, die auch XAML verwendet haben.
XAML definiert die visuelle Darstellung einer Benutzeroberfläche, und eine zugehörige CodeBehind-Datei definiert die Logik. Sie können das Ui-Design anpassen, ohne Änderungen an der Logik im CodeBehind vorzunehmen. XAML vereinfacht den Workflow zwischen Designern und Entwicklern.
Aufgrund der vielfältigen Unterstützung des visuellen Designers und der Entwurfsoberfläche für die XAML-Sprache unterstützt XAML die schnelle Ui-Prototyperstellung in den frühen Entwicklungsphasen.

Abhängig von Ihrer eigenen Rolle im Entwicklungsprozess interagieren Sie möglicherweise nicht viel mit XAML. Der Grad, in dem Sie mit XAML-Dateien interagieren, hängt auch davon ab, welche Entwicklungsumgebung Sie verwenden, ob Sie interaktive Designumgebungsfeatures wie Toolboxen und Eigenschaften-Editoren sowie den Umfang und Zweck Ihrer Windows-Runtime-App verwenden. Dennoch ist es wahrscheinlich, dass Sie während der Entwicklung der App eine XAML-Datei auf Elementebene mit einem Text- oder XML-Editor bearbeiten. Mithilfe dieser Informationen können Sie XAML in einer Text- oder XML-Darstellung sicher bearbeiten und die Gültigkeit der Deklarationen und Zweck dieser XAML-Datei beibehalten, wenn sie von Tools, Markupkompilierungsvorgängen oder der Laufzeitphase Ihrer Windows-Runtime-App verwendet wird.

Optimieren des XAML-Codes für die Ladeleistung

Hier sind einige Tipps zum Definieren von UI-Elementen in XAML mithilfe bewährter Methoden für die Leistung. Viele dieser Tipps beziehen sich auf die Verwendung von XAML-Ressourcen, sind hier jedoch in der allgemeinen XAML-Übersicht aufgeführt. Weitere Informationen zu XAML-Ressourcen finden Sie unter ResourceDictionary- und XAML-Ressourcenverweise. Einige weitere Tipps zur Leistung, einschließlich XAML, die absichtlich einige der schlechten Leistungspraktiken veranschaulicht, die Sie in Ihrem XAML vermeiden sollten, finden Sie unter Optimieren des XAML-Markups.

Wenn Sie denselben Farbpinsel häufig in XAML verwenden, definieren Sie eine SolidColorBrush Ressource als Ressource, anstatt jedes Mal eine benannte Farbe als Attributwert zu verwenden.
Wenn Sie dieselbe Ressource auf mehr als einer UI-Seite verwenden, sollten Sie sie Resources in statt auf jeder Seite definieren. Wenn hingegen nur eine Seite eine Ressource verwendet, definieren Sie sie nicht in Application.Resources und definieren Sie sie stattdessen nur für die Seite, die sie benötigt. Dies eignet sich sowohl für die XAML-Faktorierung beim Entwerfen der App als auch für die Leistung während der XAML-Analyse.
Überprüfen Sie bei Ressourcen, die Ihre App packt, auf nicht verwendete Ressourcen (eine Ressource mit einem Schlüssel, aber es gibt keinen StaticResource-Verweis in Ihrer App, die sie verwendet). Entfernen Sie diese aus Ihrem XAML-Code, bevor Sie Ihre App freigeben.
Wenn Sie separate XAML-Dateien verwenden, die Entwurfsressourcen bereitstellen (MergedDictionaries), sollten Sie nicht verwendete Ressourcen aus diesen Dateien kommentieren oder entfernen. Selbst wenn Sie einen freigegebenen XAML-Ausgangspunkt haben, den Sie in mehr als einer App verwenden oder allgemeine Ressourcen für alle Ihre App bereitstellen, ist es immer noch Ihre App, die die XAML-Ressourcen jedes Mal verpackt und möglicherweise geladen werden muss.
Definieren Sie keine UI-Elemente, die Sie nicht für die Komposition benötigen, und verwenden Sie die Standardsteuerelementvorlagen nach Möglichkeit (diese Vorlagen wurden bereits getestet und für die Ladeleistung überprüft).
Verwenden Sie Container, z Border . B. anstelle absichtlicher Überzeichnung von UI-Elementen. Zeichnen Sie im Grunde nicht mehrmals dasselbe Pixel. Weitere Informationen zur Überzeichnung und zum Testen finden Sie unter DebugSettings.IsOverdrawHeatMapEnabled.
Verwenden Sie die Standardelementevorlagen für ListView oder GridView; diese weisen spezielle Referentenlogik auf, die Leistungsprobleme beim Erstellen der visuellen Struktur für eine große Anzahl von Listenelementen löst.

Debuggen von XAML

Da XAML eine Markupsprache ist, sind einige der typischen Strategien zum Debuggen in Microsoft Visual Studio nicht verfügbar. Beispielsweise gibt es keine Möglichkeit, einen Haltepunkt in einer XAML-Datei festzulegen. Es gibt jedoch andere Techniken, mit denen Sie Probleme mit UI-Definitionen oder einem anderen XAML-Markup debuggen können, während Sie ihre App noch entwickeln.

Wenn Probleme mit einer XAML-Datei auftreten, führt dies am häufigsten dazu, dass ein System oder Ihre App eine XAML-Analyseausnahme auslöst. Immer wenn eine XAML-Analyseausnahme vorhanden ist, konnte der vom XAML-Parser geladene XAML-Parser eine gültige Objektstruktur erstellen. In einigen Fällen, z. B. wenn der XAML die erste "Seite" Ihrer Anwendung darstellt, die als visuelles Stammelement geladen wird, kann die XAML-Analyseausnahme nicht wiederhergestellt werden.

XAML wird häufig in einer IDE wie Visual Studio und einer der XAML-Entwurfsoberflächen bearbeitet. Visual Studio kann häufig während der Bearbeitung eine Entwurfszeitüberprüfung und Fehlerüberprüfung einer XAML-Quelle bereitstellen. Es kann z. B. "Wellenstriche" im XAML-Text-Editor anzeigen, sobald Sie einen ungültigen Attributwert eingeben, und Sie müssen nicht einmal auf einen XAML-Kompilierungsdurchlauf warten, um zu sehen, dass etwas mit der UI-Definition falsch ist.

Sobald die App tatsächlich ausgeführt wird, werden diese von der Common Language Runtime (CLR) als XamlParseException gemeldet, wenn alle XAML-Analysefehler zur Entwurfszeit nicht erkannt wurden. Weitere Informationen dazu, was Sie möglicherweise für eine Laufzeit von XamlParseException tun können, finden Sie unter Ausnahmebehandlung für Windows-Runtime Apps in C# oder Visual Basic.