Übersicht über XAML

  • Artikel

Aktualisiert: November 2007

In diesem Thema werden die Features der Sprache Extensible Application Markup Language (XAML) beschrieben, und es wird gezeigt, wie Sie mithilfe von XAML Windows Presentation Foundation (WPF)-Anwendungen schreiben können. Es wird in erster Linie die Implementierung von XAML in Windows Presentation Foundation (WPF) beschrieben. XAML stellt ein größeres Sprachkonzept dar als Windows Presentation Foundation (WPF).

Dieses Thema enthält folgende Abschnitte.

  • Eine deklarative Sprache mit Unterstützung der Ablaufsteuerung
  • XAML-Objektelemente
  • Festlegen von Eigenschaften
  • Verweisen auf Werte und Markuperweiterungen
  • Durch Typkonverter aktivierte Attributwerte
  • Auflistungstypen und XAML-Auflistungseigenschaften
  • XAML-Inhaltseigenschaften
  • Groß-/Kleinschreibung und Leerzeichen in XAML
  • Weitere Informationen zur XAML-Syntax
  • XAML-Stammelemente und XML-Namespaces
  • Ereignisse und XAML-Code-Behind
  • x:Name
  • Angefügte Eigenschaften und angefügte Ereignisse
  • Basisklassen und XAML
  • XAML-Sicherheit
  • Laden von XAML aus Code
  • Weitere Informationen
  • Verwandte Abschnitte

Eine deklarative Sprache mit Unterstützung der Ablaufsteuerung

XAML erleichtert das Erstellen einer Benutzeroberfläche für das .NET Framework-Programmiermodell. Sie können sichtbare Benutzeroberfläche-Elemente im deklarativen XAML-Markup erstellen und anschließend die Benutzeroberfläche-Definition mithilfe von Code-Behind-Dateien, die über partielle Klassendefinitionen an das Markup geknüpft sind, von der Laufzeitlogik trennen. Die Möglichkeit, Code in XAML mit Markup zu mischen, ist wichtig, da XML allein deklarativ ist und kein Modell für die Ablaufsteuerung vorsieht. Eine auf XML basierende deklarative Sprache ist mit Blick auf das Erstellen von Oberflächen vom Prototyp bis zur Produktionsversion sehr intuitiv, insbesondere für Personen mit Grundkenntnissen im Webdesign und in Webtechnologien. Im Gegensatz zu den meisten anderen Markupsprachen stellt XAML die Instanziierung von verwalteten Objekten direkt dar. Dieses allgemeine Entwurfsprinzip ermöglicht einen einfacheren Code- und Debugzugriff für Objekte, die in XAML erstellt werden.

XAML-Dateien sind XML-Dateien, die im Allgemeinen die Erweiterung .xaml aufweisen.

Das folgende XAML-Beispiel zeigt, wie wenig Markup erforderlich ist, um eine Schaltfläche als Teil einer Benutzeroberfläche zu erstellen. Die erstellte Schaltfläche weist durch Designstile eine visuelle Standarddarstellung und durch den Klassenentwurf ein Standardverhalten auf.

<StackPanel>
  <Button Content="Click Me"/>
</StackPanel>

XAML-Objektelemente

XAML enthält Regeln, mit denen Objektelemente Klassen oder Strukturen, Attribute Eigenschaften oder Ereignissen und XML-Namespaces CLR-Namespaces zugeordnet werden. XAML-Elemente werden entsprechend den Definitionen in Assemblys, auf die verwiesen wird, Microsoft .NET-Typen und Attribute Member dieser Typen zugeordnet.

Im vorherigen Beispiel wurden zwei Objektelemente angegeben: <StackPanel> (mit einem schließenden Tag) und <Button/> (das zudem verschiedene Attribute aufwies; Attribute werden im nachfolgenden Abschnitt beschrieben). Die Zeichenfolgen StackPanel und Button werden jeweils dem Namen einer Klasse zugeordnet, die durch WPF definiert wird und Teil der WPF-Assemblys ist. Wenn Sie ein Objektelementtag angeben, erstellen Sie eine Anweisung für die XAML-Verarbeitung, damit beim Laden der XAML-Seite eine neue Instanz der benannten Klasse erstellt wird. Die einzelnen Instanzen werden durch Aufrufen des Standardkonstruktors der zugrunde liegenden Klasse oder Struktur und Speichern des Ergebnisses erstellt. Um in XAML in einem Objektelement verwendet werden zu können, muss die Klasse oder Struktur einen öffentlichen (parameterlosen) Standardkonstruktor verfügbar machen.

Festlegen von Eigenschaften

Eigenschaften in XAML werden durch Festlegen von Eigenschaften für ein Objektelement mit verschiedenen möglichen Syntaxarten festgelegt. Welche Syntaxarten für eine bestimmte Eigenschaft verwendet werden können, hängt von den Merkmalen der Eigenschaft ab, die festgelegt werden soll.

Beim Festlegen von Eigenschaftswerten fügen Sie Objektelementen Features oder Merkmale hinzu. Der Ausgangszustand der zugrunde liegenden Objektinstanz für ein Objektelement hängt vom Verhalten des Standardkonstruktors ab. Meist verwendet die Anwendung keine ausgesprochene Standardinstanz eines angegebenen Objekts.

Attributsyntax

In XAML können Eigenschaften oft als Attribute ausgedrückt werden. Die Attributsyntax ist die optimale Syntax zum Festlegen von Eigenschaften. Sie eignet sich hervorragend für Entwickler, die in der Vergangenheit Markupsprachen verwendet haben. Mit dem folgenden Markup wird beispielsweise eine Schaltfläche mit rotem Text auf blauem Hintergrund erstellt, mit der der als Content angegebene Text angezeigt wird.

<Button Background="Blue" Foreground="Red" Content="This is a button"/>

Eigenschaftenelementsyntax

Bei einigen Eigenschaften eines Objektelements kann keine Attributsyntax verwendet werden, da die zum Bereitstellen des Eigenschaftswerts erforderlichen Objekte oder Informationen nicht angemessen als einfache Zeichenfolge ausgedrückt werden können. In diesen Fällen kann eine andere Syntax verwendet werden, die als Eigenschaftenelementsyntax bezeichnet wird. Die Eigenschaftenelementsyntax legt die Eigenschaft des enthaltenden Elements, auf die verwiesen wird, mit dem Inhalt des Tags fest. Im Allgemeinen ist der Inhalt ein Objekt des Typs, der von der Eigenschaft als Wert verwendet wird (wobei die Instanz, die den Wert festlegt, als ein anderes Objektelement festgelegt wird). Die Syntax für das Eigenschaftenelement lautet: <Typname.Eigenschaft>. Nach dem Angeben des Inhalts müssen Sie das Eigenschaftenelement wie jedes andere Element mit einem schließenden Tag schließen (mit der Syntax </Typname.Eigenschaft>). Bei Eigenschaften, bei denen sowohl die Attribut- als auch Eigenschaftenelementsyntax unterstützt wird, ergeben beide Syntaxarten dasselbe Ergebnis, wobei sich die beiden Syntaxarten in Feinheiten, etwa im Hinblick auf den Umgang mit Leerzeichen, geringfügig unterscheiden können. Wenn eine Attributsyntax verwendet werden kann, ist diese in der Regel bequemer und ermöglicht ein kompakteres Markup. Das ist jedoch lediglich eine Frage des Stils, keine technische Beschränkung. Im Folgenden Beispiel sind dieselben Eigenschaften wie im vorhergehenden Beispiel mit der Attributsyntax dargestellt, wobei hier die Eigenschaftenelementsyntax für alle Eigenschaften von Button verwendet wird.

<Button>
  <Button.Background>
    <SolidColorBrush Color="Blue"/>
  </Button.Background>
  <Button.Foreground>
    <SolidColorBrush Color="Red"/>
  </Button.Foreground>
  <Button.Content>
    This is a button
  </Button.Content>
</Button>

Die Eigenschaftenelementsyntax für XAML stellt eine erhebliche Abweichung von der einfachen XML-Interpretation des Markups dar. Für XML stellt <Typname.Eigenschaft> ein anderes Element dar, ohne notwendigerweise implizierte Beziehung zu einem übergeordneten TypeName-Element, außer dass es ein untergeordnetes Element ist. In XAML impliziert <Typname.Property> unmittelbar, dass Property eine Eigenschaft von Typname ist, die durch Eigenschaftenelementinhalte festgelegt wird, und nie ein ähnlich benanntes Element, sondern nur ein diskretes Element sein wird, das zufällig einen Punkt im Namen hat.

Vererbung von Eigenschaften und Klassen

Als XAML-Attribute in einem WPF-Element enthaltene Eigenschaften werden häufig von Basisklassen geerbt. Im vorherigen Beispiel ist die Background-Eigenschaft beispielsweise keine direkt deklarierte Eigenschaft in der Button-Klasse, wenn Sie sich die Klassendefinition, Reflektionsergebnisse oder die Dokumentation anschauen. Vielmehr wird Background von der Basisklasse Control geerbt.

Das Klassenvererbungsverhalten von WPF XAML-Elementen ist eine weitere erhebliche Abweichung von der einfachen XML-Interpretation des Markups. Die Klassenvererbung (insbesondere, wenn es sich um abstrakte Zwischenbasisklassen handelt) ist ein Grund dafür, dass es schwierig ist, die XAML-Elemente und die zulässigen Attribute mit den Schematypen, die in der Regel für die XML-Programmierung verwendet werden, wie das DTD- oder das XSD-Format, angemessen und vollständig darzustellen. Zudem steht das "X" in XAML für "extensible" (also für erweiterbar), und Erweiterbarkeit setzt voraus, dass das, "was XAML für WPF ist", vollständig dargestellt werden kann. (Die Beibehaltung getrennter XML-Namespacedefinitionen kann bei diesem Problem Abhilfe schaffen; dieses Konzept wird weiter unten in diesem Abschnitt beschrieben.)

Verweisen auf Werte und Markuperweiterungen

Markuperweiterungen sind ein XAML-Konzept. In der Attributsyntax geben geschweifte Klammern ({und}) die Verwendung einer Markuperweiterung an. Durch diese Verwendung werden bei der XAML-Verarbeitung Attributwerte nicht wie üblich als Zeichenfolgenliterale oder als direkt zeichenfolgenkonvertierbarer Werte behandelt.

Wenn Eigenschaften einen Referenztypwert enthalten, erfordern diese Eigenschaften häufig entweder die Eigenschaftenelementsyntax (die immer eine neue Instanz erstellt) oder einen Objektverweis über eine Markuperweiterung. Bei der Verwendung einer Markuperweiterung kann möglicherweise eine vorhandene Instanz zurückgegeben werden, wodurch diese Syntax flexibler ist. Zudem entsteht unter Umständen weniger zusätzlicher Aufwand für das Objekt.

Wenn zum Bereitstellen eines Attributwerts eine Markuperweiterung verwendet wird, muss von der Logik in der Sicherungsklasse der Attributwert für die entsprechende Markuperweiterung bereitgestellt werden. Die bei der WPF-Anwendungsprogrammierung am häufigsten verwendeten Markuperweiterungen sind Bindung für Datenbindungsausdrücke sowie die Ressourcenverweise StaticResource und DynamicResource. Durch die Verwendung von Markuperweiterungen können Sie mithilfe der Attributsyntax Verweiswerte für Eigenschaften bereitstellen, auch wenn diese Eigenschaft keine Attributsyntax für die direkte Objektinstanziierung unterstützt, oder ein bestimmtes Verhalten ermöglichen, das vom allgemeinen Verhalten der Anforderung abrückt, dass XAML-Eigenschaften mit Werten des Eigenschaftstyps gefüllt werden müssen.

Im folgenden Beispiel wird der Wert der Style-Eigenschaft beispielsweise mithilfe der Attributsyntax festgelegt. Die Style-Eigenschaft enthält eine Instanz der Style-Klasse, ein Referenztyp, der standardmäßig nicht innerhalb einer Zeichenfolge der Attributsyntax angegeben werden kann. In diesem Fall verweist das Attribut jedoch auf eine bestimmte Markuperweiterung, StaticResource. Bei der Verarbeitung der Markuperweiterung wird ein Verweis auf ein Format zurückgegeben, das zuvor als Ressource mit Schlüssel in einem Ressourcenwörterbuch instanziiert wurde.

<Page.Resources>
  <SolidColorBrush x:Key="MyBrush" Color="Gold"/>
  <Style TargetType="Border" x:Key="PageBackground">
    <Setter Property="Background" Value="Blue"/>
  </Style>


...


</Page.Resources>
<StackPanel>
  <Border Style="{StaticResource PageBackground}">


...


  </Border>
</StackPanel>

Ressourcen sind lediglich die Verwendung einer Markuperweiterung, die entweder durch WPF oder XAML ermöglicht wurde. Eine Verweisliste mit Markuperweiterungen finden Sie unter XAML-definierte WPF-Namespaceerweiterungen oder Sprachfeatures des XAML-Namespace (x:). Weitere Informationen über Markuperweiterungen finden Sie unter Markuperweiterungen und XAML.

Durch Typkonverter aktivierte Attributwerte

Im Abschnitt zur Attributsyntax wurde angegeben, dass es möglich sein muss, dass der Attributwert von einer Zeichenfolge festgelegt wird. Die einfache, integrierte Behandlung, wie Zeichenfolgen in andere Objekttypen oder primitive Werte konvertiert werden, hängt vom String-Typ selbst ab. Viele WPF-Typen oder -Member dieser Typen erweitern das einfache Verhalten bei der Verarbeitung von Attributen in Zeichenfolgen insofern, als dass Instanzen komplexerer Objekttypen als Attributwerte über eine Zeichenfolge angegeben werden können. Auf der Codeebene wird diese Verarbeitung durch Angeben eines CLR-Typkonverters durchgeführt, der den Attributwert der Zeichenfolge verarbeitet. Der Thickness-Strukturtyp, häufig verwendet, um die Maße eines rechteckigen Bereichs, wie z. B. eines Margin, anzugeben, ist ein Beispiel für einen Typ mit einer speziellen typkonverteraktivierten Attributsyntax, die für alle Eigenschaften bereitgestellt wird, die diesen Typ enthalten, um die Verwendung im XAML-Markup zu erleichtern. Im folgenden Beispiel wird eine typkonverteraktivierte Attributsyntax zum Bereitstellen eines Werts für ein Margin verwendet:

<Button Margin="10,20,10,30" Content="Click me"/>

Das obige Beispiel mit der Attributsyntax entspricht dem folgenden Beispiel einer umständlicheren Syntax, bei der die Margin über die Eigenschaftenelementsyntax festgelegt wird, die ein Thickness-Objektelement enthält, und bei der vier Schlüsseleigenschaften von Thickness als Attribute der neuen Instanz festgelegt werden:

<Button Content="Click me">
  <Button.Margin>
    <Thickness Left="10" Top="20" Right="10" Bottom="30"/>
  </Button.Margin>
</Button>

Ob die typkonverteraktivierte Syntax oder eine entsprechende ausführlichere Syntax verwendet wird, ist im Prinzip eine Frage des Codierungsstils. Die typkonverteraktivierte Syntax unterstützt jedoch ein optimiertes Markup. (Es gibt jedoch einige Objekte, bei denen eine Eigenschaft nur mithilfe des Typkonverters für diesen Typ festgelegt werden kann, da das Typobjekt selbst keinen Standardkonstruktor aufweist. Ein Beispiel hierfür ist Cursor.)

Weitere Informationen zur Unterstützung der typkonverteraktivierten Attributsyntax finden Sie unter TypeConverter und XAML.

Auflistungstypen und XAML-Auflistungseigenschaften

XAML gibt ein Sprachfeature an, mit dem das Objektelement, das einen Auflistungstyp darstellt, im Markup absichtlich weggelassen werden kann. Wenn ein XAML-Prozessor eine Eigenschaft behandelt, die einen Auflistungstyp annimmt, wird implizit ein entsprechender Auflistungstyp erstellt, auch wenn das Objektelement für diese Auflistung im Markup nicht vorhanden ist. Auf den SDK-Referenzseiten für Auflistungstypen wird diese Syntax mit dem absichtlichen Weglassen des Objektelements für eine Auflistung in den XAML-Syntaxbereichen gelegentlich als implizite Auflistungssyntax angegeben.

Die implizite Auflistungssyntax ist für Arrays oder für Typen verfügbar, die IList oder IDictionary implementieren.

Sie haben bereits ein Beispiel für eine implizite Auflistungssyntax gesehen, ohne dass diese als solche bezeichnet wurde, nämlich im Beispiel für XAML-Ressourcen:

<Page.Resources>
  <SolidColorBrush x:Key="MyBrush" Color="Gold"/>
  <Style TargetType="Border" x:Key="PageBackground">
    <Setter Property="Background" Value="Blue"/>
  </Style>


...


</Page.Resources>
<StackPanel>
  <Border Style="{StaticResource PageBackground}">


...


  </Border>
</StackPanel>

Mit Ausnahme des Stammelements ist jedes Objektelement auf einer Seite, das als untergeordnetes Element eines anderen Elements geschachtelt ist, bereits ein Element, das eines oder beide der folgenden Fälle darstellt: ein Member einer impliziten Auflistungseigenschaft des übergeordneten Elements oder ein Element, das den Wert der XAML-Inhaltseigenschaft für das übergeordnete Element angibt. (XAML-Inhaltseigenschaften werden in einem späteren Abschnitt beschrieben.) Anders ausgedrückt handelt es sich bei der Beziehung von übergeordneten und untergeordneten Elementen auf einer Markupseite um ein einzelnes Objekt auf der Stammebene und bei jedem Objektelemente unter dem Stamm entweder um eine einzelne Instanz, die einen Eigenschaftenwert des übergeordneten Elements bereitstellt, oder um eines der Elemente in einer Auflistung, bei der es sich ebenfalls um den Eigenschaftenwert einer Auflistung des übergeordneten Elements handelt. Im Beispiel mit den Ressourcen nimmt die Resources-Eigenschaft ein Objekt des Typs ResourceDictionary an. Das folgende Beispiel enthält eine entsprechende Syntax, wobei das Objektelement für das ResourceDictionary explizit angegeben wird.

<Page.Resources>
  <ResourceDictionary>
      <SolidColorBrush x:Key="MyBrush" Color="Gold"/>
      <Style TargetType="Border" x:Key="PageBackground">
        <Setter Property="Background" Value="Blue"/>
      </Style>


...


  </ResourceDictionary>
</Page.Resources>
<StackPanel>
  <Border Style="{StaticResource PageBackground}">


...


    </Border>
  </StackPanel>
</Page>

Die Resources-Auflistung ist ein Beispiel für eine Auflistungseigenschaft, die in vielen häufig verwendeten Elementen auf WPF-Frameworkebene vorkommt. Um diese Eigenschaft in XAML angeben zu können, ist die Eigenschaftenelementsyntax erforderlich. Jedes eingeschlossene Objektelement innerhalb des Eigenschaftenelements wird ein Element der Auflistung (eine IDictionary-Implementierung). Obwohl der Auflistungstyp in der Regel eine Eigenschaft oder einen Indexer aufweist, der die Elemente enthält, kann diese Eigenschaft nicht in Markup angegeben werden. Sie ist vollständig impliziert. Beim ResourceDictionary ist diese Eigenschaft der Item-Indexer.

Ein ausführlicheres Beispiel für die Verwendung des Ressourcenwörterbuchs finden Sie unter Gewusst wie: Definieren einer Ressource und Verweisen auf eine Ressource.

XAML-Inhaltseigenschaften

XAML gibt ein Sprachfeature an, mit dem jede Klasse, die als XAML-Objektelement verwendet werden kann, exakt eine der eigenen Eigenschaften als XAML-Inhaltseigenschaft für Instanzen der Klasse bestimmen kann. Wenn ein XAML-Prozessor ein Objektelement behandelt, das eine XAML-Inhaltseigenschaft aufweist, werden alle untergeordneten XML-Elemente dieses Objektelements so verarbeitet, als wären sie in einem impliziten Eigenschaftenelementtag enthalten, das diese Inhaltseigenschaft darstellt. Innerhalb des Markups kann die Eigenschaftenelementsyntax für die XAML-Inhaltseigenschaft weggelassen werden. Alle untergeordneten Elemente, die Sie im Markup angeben, werden zum Wert der XAML-Inhaltseigenschaft.

Sie haben bereits ein Beispiel für eine XAML-Inhaltseigenschaft gesehen, ohne dass diese als solche bezeichnet wurde, nämlich das erste Beispiel in diesem Thema:

<StackPanel>
  <Button Content="Click Me"/>
</StackPanel>

In diesem Beispiel ist Button ein untergeordnetes Element von StackPanel. Hierbei handelt es sich um ein optimiertes und intuitives Markup, bei dem zwei Tags aus zwei unterschiedlichen Gründen weggelassen werden.

  • Weggelassenes StackPanel.Children-Eigenschaftenelement: StackPanel wird von Panel abgeleitet. Panel definiert Panel.Children als XAML-Inhaltseigenschaft. Alle abgeleiteten Klassen von Panel verfügen somit über diese XAML-Inhaltseigenschaft, und das Eigenschaftenelement für Panel.Children kann weggelassen werden.

  • Weggelassenes UIElementCollection-Objektelement: Die Panel.Children-Eigenschaft nimmt den Typ UIElementCollection an, der IList implementiert. Daher kann das UIElementCollection-Objektelementtag gemäß den für XAML definierten Regeln für Auflistungen weggelassen werden. In diesem Fall kann UIElementCollection nicht als Objektelement instanziiert werden. Sie haben nicht einmal die Möglichkeit, dieses Auflistungsobjekt explizit zu deklarieren. Das kommt daher, weil UIElementCollection keinen Standardkonstruktor bereitstellt. Einige andere WPF-Auflistungstypen stellen ebenfalls keine Konstruktoren für die Verwendung von Objektelementen bereit, da die XAML-Auflistungssyntaxverarbeitung die implizite Verarbeitung in XAML zulässt. Daher wird das UIElementCollection-Objektelement im Beispiel als kommentiert dargestellt. Wenn das Objektelement nicht kommentiert wäre, würde es nicht kompiliert werden.

<StackPanel>
  <StackPanel.Children>
    <!--<UIElementCollection>-->
    <Button>
      <Button.Content>
        Click Me
      </Button.Content>
    </Button>
    <!--</UIElementCollection>-->
  </StackPanel.Children>
</StackPanel>

Innerer Text und XAML-Inhaltseigenschaften

Vom StackPanel-/Button-Beispiel gibt es noch eine andere Variante.

<StackPanel>
  <Button>Click Me</Button>
</StackPanel>

Beachten Sie die Änderung im Hinblick darauf, wie der Anzeigetext für Button angegeben wird. Zuvor wurde die Content-Eigenschaft in der Attributsyntax angegeben. Jetzt ist die Anzeigereihenfolge der innere Text innerhalb eines Button-Objektelements. Diese Syntax funktioniert, da Content die XAML-Inhaltseigenschaft der Button-Basisklasse ContentControl ist. Die Zeichenfolge innerhalb des Elements wird anhand des Eigenschaftentyps der Content-Eigenschaft ausgewertet, bei der es sich um Object handelt. Object konvertiert keine Zeichenfolgentypen. Daher wird der Wert der Content-Eigenschaft zum Zeichenfolgenliteral. Alternativ kann es sich beim Inhalt in Button auch um ein einzelnes Object handeln. Steuerelemente wie Button definieren im Allgemeinen die XAML-Inhaltseigenschaft für die Klasse so, dass die XAML-Inhaltseigenschaft für Benutzeroberflächen- und Anzeigetext, für die Erstellung von Steuerelementen oder für beides verwendet werden kann.

Die Fähigkeit, Zeichenfolgen als Inhalt in das Element einzufügen, um ein Markup zu erstellen, das anderen üblichen Markupsprachen gleicht, ist für das Flussdokumentmodell (ausführliche Informationen finden Sie unter Dokumente in Windows Presentation Foundation) sowie für die Lokalisierung (siehe Globalisierung für Windows Presentation Foundation) besonders wichtig.

XAML-Inhaltseigenschaftenwerte müssen zusammenhängend sein

Der Wert einer XAML-Inhaltseigenschaft muss entweder vor oder nach anderen Eigenschaftenelementen in diesem Objektelement vollständig angegeben werden. Dies gilt unabhängig davon, ob der Wert einer XAML-Inhaltseigenschaft als Zeichenfolge oder als ein oder mehrere Objekte angegeben wird. Das folgende Markup wird beispielsweise nicht kompiliert:

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

Dieses Markup ist im Wesentlichen nicht zulässig, da die Inhaltseigenschaft doppelt festgelegt wird, wenn diese Syntax durch die Verwendung der Eigenschaftenelementsyntax für die Inhaltseigenschaft explizit ist:

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

Ein ähnliches, nicht zulässiges Beispiel für den Fall, dass es sich bei der Inhaltseigenschaft um eine Auflistung handelt und untergeordnete Elemente mit Eigenschaftenelementen vermischt werden:

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

Inhaltsmodelle

Eine Klasse unterstützt möglicherweise eine Verwendung als XAML-Element in Bezug auf die Syntax, aber dieses Element funktioniert in einer Anwendung oder auf einer Seite nur einwandfrei, wenn es in einer erwarteten Position eines allgemeinen Inhaltsmodells oder einer allgemeinen Elementstruktur eingefügt wird. Ein MenuItem-Element darf beispielsweise nur als untergeordnetes Element einer von MenuBase abgeleiteten Klasse, wie Menu, eingefügt werden. Inhaltsmodelle für bestimmte Elemente sind als Teil der Hinweise auf den Klassenseiten für Steuerelemente und andere WPF-Klassen dokumentiert, die als XAML-Elemente verwendet werden können. Bei einigen Steuerelementen, mit komplexeren Inhaltsmodellen, ist das Inhaltsmodell als eigenes Thema dokumentiert. Informationen hierzu finden Sie unter Inhaltsmodelle.

Groß-/Kleinschreibung und Leerzeichen in XAML

Bei XAML muss die Groß- und Kleinschreibung beachtet werden. Objektelemente, Eigenschaftenelemente und Attributnamen müssen beim Vergleich anhand des Namens des zugrunde liegenden Typs oder mit einem Member eines Typs mit der richtigen Groß-/Kleinschreibung angegeben werden. Bei den Werten für Attribute muss die Groß-/Kleinschreibung nicht immer beachtet werden. Ob die Groß-/Kleinschreibung beachtet werden muss, hängt vom Verhalten des der Eigenschaft zugeordneten Typkonverters, der den Wert annimmt, oder vom Eigenschaftenwerttyp ab. Eigenschaften, die beispielsweise den Boolean-Typ annehmen, können entweder true oder True als entsprechende Werte annehmen, aber nur deswegen, weil die Standardkonvertierung des Zeichenfolgentyps für Boolean diese bereits als Entsprechungen zulässt.

XAML-Prozessoren und -Serialisierungsprogramme ignorieren oder löschen alle nicht signifikanten Leerzeichen und normalisieren alle signifikanten Leerzeichen. Dieses Verhalten hat im Allgemeinen nur Folgen, wenn Sie innerhalb von XAML-Inhaltseigenschaften Zeichenfolgen angeben. Vereinfacht ausgedrückt: XAML konvertiert Leerzeichen, Zeilenvorschub und Tabulatorzeichen in Leerzeichen und behält ein Leerzeichen bei, wenn sich dieses an einem Ende einer zusammenhängenden Zeichenfolge befindet. Die Behandlung von Leerzeichen bei XAML wird in diesem Thema nicht erschöpfend behandelt. Weitere Informationen finden Sie unter Leerstellenverarbeitung in XAML.

Weitere Informationen zur XAML-Syntax

Implizite Auflistungssyntax und XAML-Inhaltseigenschaften sind Features der XAML-Sprache, die das Weglassen bestimmter abgeleiteter Tags ermöglichen. Ziel dieser Features ist es, die Beziehung zwischen untergeordneten und übergeordneten Elementen auf einer Seite beim Erstellen oder Überprüfen des Markups deutlicher darzustellen.

Weitere Informationen zur Attributsyntax und zur Eigenschaftenelementsyntax sowie zu anderen Begriffen, die bei der Beschreibung der XAML-Syntax in der SDK-Dokumentation verwendet werden, finden Sie unter Terminologie der XAML-Syntax. Das Thema Terminologie der XAML-Syntax eignet sich ebenfalls als Einführung, wenn Sie beim Erstellen einer benutzerdefinierten Klasse XAML verwenden möchten.

XAML-Stammelemente und XML-Namespaces

Eine XAML-Datei darf nur über ein Stammelement verfügen, wenn es sich sowohl um eine regelkonforme XML-Datei als auch um eine zulässige XAML-Datei handeln soll. In der Regel sollten Sie ein Element auswählen, das Teil des Anwendungsmodells ist (z. B. Window oder Page für eine Seite, ResourceDictionary für ein externes Wörterbuch oder Application für den Stamm der Anwendungsdefinition). Das folgende Beispiel zeigt das Stammelement einer typischen XAML-Datei für eine WPF-Seite mit dem Stammelement Page.

<Page
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"


...


</Page>

Das Stammelement enthält darüber hinaus auch die Attribute xmlns und xmlns:x. Diese Attribute geben einem XAML-Prozessor an, welche XML-Namespaces die Elementdefinitionen für Elemente enthalten, auf die das Markup verweist. Das xmlns-Attribut gibt ausdrücklich den XML-Standardnamespace an. Innerhalb des XML-Standardnamespace können Objektelemente im Markup ohne Präfix angegeben werden. Bei den meisten WPF-Anwendungen sowie bei fast allen Beispielen in den WPF-Abschnitten im SDK wird der XML-Standardnamespace dem WPF-Namespace https://schemas.microsoft.com/winfx/2006/xaml/presentation zugeordnet. Das xmlns:x-Attribut gibt einen zusätzlichen XML-Namespace an, der dem XAML-Sprachnamespace https://schemas.microsoft.com/winfx/2006/xaml zuordnet. Erforderliche, durch die XAML-Angaben definierte Sprachkomponenten erhalten das Präfix x:, wenn im Markup einer Datei mit dieser Zuordnung auf sie verwiesen wird. Diese Verwendung von xmlns zum Definieren eines Bereichs für die Verwendung und Zuordnung stimmt mit der XML 1.0-Spezifikation überein. Beachten Sie, dass die xmlns-Attribute nur beim Stammelement der einzelnen Seiten sowie bei der Anwendungsdefinition unbedingt erforderlich sind, sofern diese im Markup bereitgestellt wird. xmlns-Definitionen gelten für alle untergeordneten Elemente des Stamms (auch dieses Verhalten entspricht der XML 1.0-Spezifikation für xmlns). xmlns-Attribute sind auch bei anderen Elementen unterhalb des Stamms zulässig und gelten für alle untergeordneten Elemente des definierenden Elements. Diese Verwendung ist jedoch nicht typisch, da regelmäßige Definitionen oder Neudefinitionen von XML-Namespaces ein XAML-Markupformat ergeben können, das schwer zu lesen ist.

Die WPF-Assemblys enthalten bekanntermaßen die Typen, die aufgrund der Konfiguration, die Teil der Projektbuilddatei ist, die WPF-Zuordnungen zum XML-Standardnamespace unterstützen. Assemblys werden auch in den Zieldateien zugeordnet. Daher müssen lediglich die xmlns-Namespaces zugeordnet werden, um auf XAML-Elemente zu verweisen, die aus WPF-Assemblys stammen. Eigene benutzerdefinierte Assemblys oder Assemblys außerhalb von WPF können Sie als Teil der xmlns-Zuordnung angeben. In der Regel wird dann ein anderes Präfix verwendet. Es ist jedoch auch möglich, einen anderen XML-Namespace als Standard auszuwählen und WPF einem Präfix zuzuordnen. Weitere Informationen zum Zusammenhang zwischen XML-Namespaces und den Namespaces des Sicherungscodes in Assemblys finden Sie unter XAML-Namespaces und Namespacezuordnung.

Das Präfix x:

Im vorherigen Beispiel mit dem Stammelement wurde das Präfix x: zum Zuordnen des XAML-XML-Namespace https://schemas.microsoft.com/winfx/2006/xamlverwendet. Hier wird das Präfix x: verwendet, um den XAML-XML-Namespace in den Vorlagen für Projekte, in Beispielen und in der Dokumentation in diesem SDK zuzuordnen. Der x:-Präfix/XAML-XML-Namespace enthält verschiedene Programmierkonstrukte, die Sie in Ihrem XAML-Code recht häufig verwenden werden. Im Folgenden finden Sie eine Auflistung der am häufigsten verwendeten x:-Präfix/XAML-Namespace-Programmierkonstrukte:

  • x:Key: Legt für die einzelnen Ressourcen in einem ResourceDictionary einen eindeutigen Schlüssel fest. x:Key wird wohl 90 % der Verwendung von x: im Markup Ihrer Anwendung ausmachen.

  • x:Class: Gibt den CLR-Namespace und -Klassennamen für die Klasse an, die den Code-Behind für eine XAML-Seite angibt. Eine Klasse dieser Art muss vorhanden sein, um den Code-Behind unterstützen zu können. Aus diesem Grund ist x: fast immer zugeordnet, auch wenn keine Ressourcen vorhanden sind.

  • x:Name: Gibt einen Laufzeitobjektnamen für die Instanz an, die nach der Verarbeitung eines Objektelements im Laufzeitcode vorhanden ist. Sie verwenden x:Name, wenn Elemente benannt werden und die entsprechende Name-Eigenschaft auf WPF-Frameworkebene nicht unterstützt wird. Dies ist bei bestimmten Animationsszenarien der Fall.

  • x:Static: Ermöglicht einen Wertverweis, der einen statischen Wert abruft, der nicht anderweitig als XAML-kompatible Eigenschaft festgelegt werden kann. 

  • x:Type: Erstellt anhand eines Typnamens einen Type-Verweis. Wird verwendet, um Attribute anzugeben, die Type annehmen, wie z. B. Style.TargetType, obwohl die Eigenschaft meist eine eigene Konvertierung von Zeichenfolgen in Type aufweist, sodass die Verwendung von x:Type optional ist.

Es gibt weitere Programmierungskonstrukte im x:-Präfix/XAML-Namespace, die nicht so häufig verwendet werden. Ausführlichere Informationen hierzu finden Sie unter Sprachfeatures des XAML-Namespace (x:).

Ereignisse und XAML-Code-Behind

Die meisten WPF-Anwendungen bestehen sowohl aus Markup als auch aus Code-Behind. Innerhalb eines Projekts wird der XAML-Code als .xaml-Datei geschrieben, und zum Schreiben einer Code-Behind-Datei wird eine CLR-Sprache wie Microsoft Visual Basic .NET oder C# verwendet. Beim Kompilieren einer XAML-Datei wird der Speicherort der XAML-Code-Behind-Datei für alle XAML-Seiten durch die Angabe eines Namespace und einer Klasse als x:Class-Attribut des Stammelements der XAML-Seite identifiziert.

Im Beispiel haben Sie bisher verschiedene Schaltflächen gesehen, aber keiner dieser Schaltflächen war ein logisches Verhalten zugeordnet. Der erste Mechanismus auf Anwendungsebene zum Hinzufügen eines Verhaltens für ein Objektelement besteht darin, ein vorhandenes Ereignis der Elementklasse zu verwenden und einen spezifischen Handler für dieses Ereignis zu schreiben, der beim Aufrufen dieses Ereignisses zur Laufzeit aufgerufen wird. Der Ereignisname und der Name des zu verwendenden Handlers werden im Markup angegeben, während der Code, der den Handler implementiert, im Code-Behind definiert wird.

<Page 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="MyNamespace.MyPageCode">
  <Button Click="ClickHandler" >Click Me!</Button>
</Page>

namespace MyNamespace
{
  public partial class MyPageCode
  {
    void ClickHandler(object sender, RoutedEventArgs e)
    {
      Button b = e.Source as Button;
      b.Background = Brushes.Red;
    }
  }
}

Beachten Sie, dass die Code-Behind-Datei den CLR-Namespace MyNamespace verwendet und MyPageCode als partielle Klasse in diesem Namespace deklariert. Dies entspricht dem x:Class-Attributwert von MyNamespace.MyPageCode, der im Markupstamm bereitgestellt wurde. Der Compiler erstellt für jede kompilierte XAML-Seite automatisch eine partielle Klasse, indem er eine Klasse vom Stammelementtyp ableitet. Wenn Sie Code-Behind bereitstellen, der dieselbe partielle Klasse definiert, wird der resultierende Code im selben Namespace und in derselben Klasse der kompilierten Anwendung kombiniert.

Weitere Informationen zu den Anforderungen für die Code-Behind-Programmierung finden Sie im Abschnitt "Anforderungen für Code-Behind, Ereignishandler und partielle Klassen" im Thema Code-Behind und XAML.

Wenn Sie keine eigene Code-Behind-Datei erstellen möchten, können Sie den Code auch in einer XAML-Datei inline erstellen. Inlinecode ist jedoch eine weniger vielseitige Technik mit erheblichen Einschränkungen. Ausführlichere Informationen hierzu finden Sie unter Code-Behind und XAML.

Ereignisattributsyntax

Wenn Sie das Verhalten durch Ereignisse im Markup angeben, fügen Sie Handler in der Regel mithilfe der Attributsyntax an. Das Objektelement wird beim Angeben des Ereignisattributs zu der Instanz, die das Ereignis überwacht und den Handler aufruft. Der Name des zu behandelnden Ereignisses, ist der Attributname. Der Attributwert ist der Methodenname des Handlers, den Sie definieren. Sie müssen dann die Handlerimplementierung in Code-Behind bereitstellen, wobei der Handler auf dem Delegaten für dieses Ereignis basiert. Sie schreiben den Handler in Code-Behind in einer Programmiersprache wie Microsoft Visual Basic .NET oder C#.

Alle WPF-Ereignisse melden beim Aufrufen des Ereignisses Ereignisdaten. Ereignishandler können auf diese Ereignisdaten zugreifen. Im vorherigen Beispiel ruft der Handler die gemeldete Ereignisquelle über die Ereignisdaten ab und legt dann für diese Quelle Eigenschaften fest.

Routingereignisse

Ein bestimmtes Ereignisfeature, das eindeutig und für WPF wichtig ist, ist ein Routingereignis. Mithilfe von Routingereignissen kann ein Element ein von einem anderen Element aufgerufenes Ereignis behandeln, vorausgesetzt, die Elemente sind über eine Elementstrukturbeziehung miteinander verbunden. Beim Angeben der Ereignisbehandlung mit einem XAML-Attribut kann das Routingereignis für jedes Element aufgelistet und in jedem Element behandelt werden, auch in Elementen, bei denen dieses spezielle Ereignis nicht in der Klassenmembertabelle aufgeführt ist. Dies wird durch das Qualifizieren des Ereignisnamensattributs mit dem Namen der übergeordneten Klasse erzielt. Das übergeordnete StackPanel im aktuellen StackPanel/Button-Beispiel kann beispielsweise einen Handler für das Click-Ereignis der Schaltfläche des untergeordneten Elements registrieren, indem er das Button.Click-Attribut für das StackPanel-Objektelement angibt, wobei der Handlername als Attributwert verwendet wird. Weitere Informationen finden Sie unter Übersicht über Routingereignisse.

x:Name

Die Objektinstanz, die durch die Verarbeitung eines Objektelements erstellt wird, weist standardmäßig keinen eindeutigen Bezeichner oder inhärenten Objektverweis auf, der im Code verwendet werden kann. Wenn Sie im Code einen Konstruktor aufrufen, verwenden Sie fast immer das Konstruktorergebnis zum Festlegen einer Variablen auf die erstellte Instanz, sodass Sie später im Code auf die Instanz verweisen können. Um standarisierten Zugriff auf Objekte bereitzustellen, die über eine Markupdefinition erstellt wurden, definiert XAML das x:Name-Attribut . Sie können den Wert des x:Name-Attributs auf ein beliebiges Objektelement festlegen. Im Code-Behind entspricht der ausgewählte Bezeichner einer Instanzvariablen, die auf die erstellte Instanz verweist. Benannte Elemente funktionieren in jeder Hinsicht wie Objektinstanzen (der Name verweist nur auf diese Instanz), und der Code-Behind kann auf die benannten Elemente verweisen, um Laufzeitinteraktionen innerhalb der Anwendung zu behandeln.

XAML-Elemente auf WPF-Frameworkebene erben eine Name-Eigenschaft, die dem im x:Name-Attribut definierten XAML entspricht. Bestimmte andere Klassen stellen darüber hinaus auch Entsprechungen auf Eigenschaftenebene für x:Name bereit, das auch allgemein als Name-Eigenschaft definiert ist. Wenn in der Membertabelle für das ausgewählte Element keine Name-Eigenschaft vorhanden ist, verwenden Sie stattdessen x:Name.

Im folgenden Beispiel wird Name auf ein StackPanel-Element festgelegt. Dann verweist ein Handler in einer Button innerhalb dieser StackPanel über den vom Name festgelegten Instanzenverweis buttonContainer auf das StackPanel.

<StackPanel Name="buttonContainer">


...


  <Button Click="RemoveThis">Click to remove this button</Button>
</StackPanel>

void RemoveThis(object sender, RoutedEventArgs e)
{
    FrameworkElement fe = e.Source as FrameworkElement;
    if (buttonContainer.Children.Contains(fe))
    {
        buttonContainer.Children.Remove(fe);
    }
}

Der Name für eine Instanz wird ebenso wie eine Variable durch einen Bereich bestimmt, sodass erzwungen werden kann, dass Namen in einem bestimmten vorhersehbaren Bereich eindeutig sind. Das primäre Markup, das eine Seite definiert, gibt einen eindeutigen Namensbereich an, wobei die Grenzen des Namensbereichs dem Stammelement dieser Seite entsprechen. Andere Markupquellen, wie Formate oder Vorlagen in Formaten, können zur Laufzeit mit einer Seite interagieren. Markupquellen dieser Art verfügen häufig über eigene Namensbereiche, die nicht unbedingt mit dem Namensbereich der Seite in Verbindung stehen. Weitere Informationen zu x:Name und Namensbereichen finden Sie unter Name, x:Name-Attribut oder WPF-Namescopes.

Angefügte Eigenschaften und angefügte Ereignisse

XAML gibt ein Sprachfeature an, mit dem es möglich ist, bestimmte Eigenschaften oder Ereignisse für ein Element unabhängig davon anzugeben, ob die Eigenschaft oder das Element in der Membertabelle für das Element vorhanden ist, für das die Eigenschaft festgelegt wird. Die Eigenschaftenversion dieses Features wird als angefügte Eigenschaft bezeichnet, die Ereignisversion als angefügtes Ereignis. Im Prinzip können Sie sich angefügte Eigenschaften und Ereignisse als globale Member vorstellen, die unabhängig von der Klassenhierarchie auf ein Element oder eine Klasse festgelegt werden können.

Angefügte Eigenschaften in XAML werden in der Regel über die Attributsyntax verwendet. In der Attributsyntax geben Sie eine angefügte Eigenschaft in der Form Besitzertyp.Eigenschaftenname an. Oberflächlich betrachtet gleicht dies der Verwendung eines Eigenschaftenelements. In diesem Fall unterscheidet sich jedoch der angegebene Besitzertyp immer von dem Typ des Objektelements, auf das die angefügte Eigenschaft festgelegt wird. Besitzertyp ist der Typ, der die Accessormethoden bereitstellt, die der XAML-Prozessor benötigt, um den Wert der angefügten Eigenschaft abzurufen oder festzulegen. Das typischste Szenario für angefügte Eigenschaften besteht darin, untergeordneten Elementen zu ermöglichen, dem übergeordneten Element einen Eigenschaftenwert zu melden.

Im folgenden Beispiel wird die angefügte Eigenschaft DockPanel.Dock dargestellt. Die DockPanel-Klasse definiert die Accessoren für DockPanel.Dock und besitzt deshalb die angefügte Eigenschaft. Die DockPanel-Klasse enthält darüber hinaus auch die Logik, die die untergeordneten Elemente durchläuft und insbesondere die einzelnen Elemente auf den festgelegten Wert DockPanel.Dock überprüft. Wenn ein Wert gefunden wird, wird dieser Wert bei der Anordnung der untergeordneten Elemente verwendet. Die Verwendung der angefügten Eigenschaft DockPanel.Dock und diese Anordnungsmöglichkeit stellen die Motivation für die DockPanel-Klasse dar.

<DockPanel>
  <Button DockPanel.Dock="Left" Width="100" Height="20">I am on the left</Button>
  <Button DockPanel.Dock="Right" Width="100" Height="20">I am on the right</Button>
</DockPanel>

In Windows Presentation Foundation (WPF) werden alle angefügten Eigenschaften auch als Abhängigkeitseigenschaften implementiert. Ausführlichere Informationen hierzu finden Sie unter Übersicht über angefügte Eigenschaften.

Angefügte Ereignisse verwenden ein ähnliches Besitzertyp.Ereignisname-Format der Attributsyntax. Wie bei nicht angefügten Ereignissen gibt der Attributwert für ein angefügtes Ereignis in XAML den Namen der Handlermethode an, die bei der Behandlung des Ereignisses im Element aufgerufen wird. 

Ein Szenario, bei dem angefügte Ereignisse verwendet werden, besteht bei Geräteeingabeereignissen, die von jedem Element behandelt werden können, wie z. B. Maustasten. Ein Beispiel für ein angefügtes Ereignis dieser Art: Mouse.MouseDown. Die meisten Elemente auf WPF-Frameworkebene können dieses Ereignis jedoch ohne angefügtes Ereignis verwenden. Dies ist darauf zurückzuführen, dass die Basiselementklasse UIElement einen Alias für das angefügte Element Mouse.MouseDown erstellt und diesen Alias in der Membertabelle UIElement (als MouseDown) verfügbar macht. Daher brauchen Sie auf einer XAML-Seite oder bei der Windows Presentation Foundation (WPF)-Anwendungsprogrammierung normalerweise keine Syntax für angefügte Ereignisse anzugeben. Eine Ausnahme stellt die Verwendung von benutzerdefinierten Elementen oder Objektelementen dar, die nicht von UIElement abgeleitet wurden, aber dennoch eine optische Darstellung haben (kommt selten vor). In WPF werden alle angefügten Ereignisse auch als Routingereignisse implementiert. ContentElement macht zudem Aliase für die Eingabeereignisse zur Verwendung durch das Flussdokumentmodell verfügbar. Ausführliche Informationen hierzu finden Sie unter Übersicht über Routingereignisse und Übersicht über die Eingabe.

Aufbau des Stammelements einer XAML-Seite

In der folgenden Tabelle ist der Aufbau des Stammelement einer typischen XAML-Seite mit den in diesem Thema beschriebenen spezifischen Attributen eines Stammelements dargestellt:

<Page

Öffnendes Objektelement des Stammelements

xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"

Der Standardnamespace (WPF)

xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"

Der XAML-Namespace

x:Class="MyNamespace.MyPageCode"

Die Deklaration der partiellen Klasse, die das Markup mit einem in dieser partiellen Klasse definierten Code-Behind verbindet

>

Ende des Objektelements für den Stamm, noch nicht geschlossen, da die Seite untergeordnete Elemente enthält

Basisklassen und XAML

Zugrunde liegender XAML-Code und die zugehörigen Schemas stellen eine Auflistung von Klassen dar, die CLR-Objekten sowie in XAML zu verwendenden Markupelementen entsprechen. Es können jedoch nicht alle Klassen Elementen zugeordnet werden. Abstrakte Klassen, wie ButtonBase, sowie bestimmte nicht abstrakte Basisklassen werden für die Vererbung im CLR-Objektmodell verwendet und unterstützten keine entsprechenden XAML-Markuptags. Basisklassen, z. B. abstrakte Klassen, sind dennoch wichtig für die XAML-Entwicklung, da jedes konkrete XAML-Element Member von einer Basisklasse in der eigenen Hierarchie erbt. Häufig enthalten diese Member Eigenschaften, die als Attribute für das Element festgelegt werden können, oder Ereignisse, die behandelt werden können. FrameworkElement ist die konkrete Benutzeroberfläche-Basisklasse von WPF auf der WPF-Frameworkebene. Beim Entwerfen von Benutzeroberfläche werden Sie verschiedene Form-, Panel-, Decorator- oder Steuerelement-Klassen verwenden, die alle vom FrameworkElement abgeleitet werden. Eine verwandte Klasse, FrameworkContentElement, unterstützt für eine Flusslayoutdarstellung geeignete, dokumentorientierte Elemente und verwendet hierzu APIs, die die APIs in FrameworkElement explizit spiegeln. Aufgrund der Kombination aus Attributen auf Elementebene und CLR-Objektmodell verfügen Sie über allgemeine Eigenschaften, die unabhängig vom exakten Elementtyp und der zugrunde liegenden Klasse für die meisten konkreten XAML-Elemente festgelegt werden können.

XAML-Sicherheit

XAML ist eine Markupsprache, die die Objektinstanziierung und -Ausführung direkt darstellt. Daher verfügen in XAML erstellte Elemente über dieselbe Fähigkeit, mit Systemressourcen (z. B. Netzwerkzugriff, Dateisystemeingabe/-ausgabe) zu interagieren, wie der entsprechend erstellte Code.

WPF unterstützt das .NET-Sicherheitsframework Codezugriffssicherheit (Code Access Security, CAS). Das bedeutet, dass in der Internetzone ausgeführter WPF-Inhalt über eingeschränkte Berechtigungen zum Ausführen verfügt. "Loose XAML" (Seiten mit nicht kompiliertem XAML-Code, der beim Laden von einem XAML-Viewer interpretiert wird) und XAML-Browseranwendung (XBAP) werden normalerweise in dieser Internetzone ausgeführt und verwenden dieselben Berechtigungen. Wenn XAML-Code in eine voll vertrauenswürdige Anwendung geladen wird, hat er denselben Zugriff auf die Systemressourcen wie die Hostanwendung. Weitere Informationen finden Sie unter Windows Presentation Foundation - Sicherheit bei teilweiser Vertrauenswürdigkeit.

Laden von XAML aus Code

XAML kann zum Definieren einer ganzen Benutzeroberfläche verwendet werden, eignet sich jedoch auch, um nur einen Teil der Benutzeroberfläche in XAML zu definieren. Dadurch sind partielle Anpassungen, die lokale Speicherung von Informationen, die Verwendung von XAML zum Bereitstellen eines Geschäftsobjekts oder eine Reihe anderer möglicher Szenarien möglich. Der Schlüssel zu diesen Szenarien ist die XamlReader-Klasse und die zugehörige Load-Methode. Als Eingabe dient eine XAML-Datei und als Ausgabe ein Objekt, das die gesamte Laufzeitstruktur von Objekten darstellt, die über dieses Markup erstellt wurden. Das Objekt kann dann als Eigenschaft eines anderen Objekts eingefügt werden, das in der Anwendung bereits vorhanden ist. Vorausgesetzt, bei der Eigenschaft handelt es sich um eine geeignete Eigenschaft im Inhaltsmodell mit tatsächlichen Anzeigefunktionen, die das Ausführungsmodul benachrichtigt, wenn neuer Inhalt zur Anwendung hinzugefügt wurde, können Sie den Inhalt einer aktiven Anwendung recht einfach ändern, indem Sie ihn in XAML laden. Beachten Sie, dass diese Funktion aufgrund der offensichtlichen Sicherheitsrisiken beim Laden von Dateien in aktive Anwendungen im Allgemeinen nur in voll vertrauenswürdigen Anwendungen verfügbar ist.

Weitere Informationen

Dieses Thema enthält eine grundlegende Einführung in die Begriffe und Terminologie der XAML-Syntax. Weitere Informationen zu den hier verwendeten Begriffen finden Sie unter Terminologie der XAML-Syntax.

Wenn Sie es noch nicht getan haben, rufen Sie das Lernprogramm Erste Schritte mit Windows Presentation Foundation auf. Beim Erstellen der im Lernprogramm beschriebenen Markupanwendung werden die zahlreichen, in diesem Thema beschriebenen Begriffe im Rahmen der Übungen vertieft.

WPF verwendet ein bestimmtes Anwendungsmodell, das auf der Application-Klasse basiert. Ausführlichere Informationen hierzu finden Sie unter Übersicht über die Anwendungsverwaltung.

Unter Erstellen einer WPF-Anwendung (WPF) finden Sie ausführlichere Informationen zum Erstellen von XAML-Anwendungen über die Befehlszeile und mit Microsoft Visual Studio.

Übersicht über Abhängigkeitseigenschaften enthält weitere Informationen zur Vielseitigkeit von Eigenschaften in Windows Presentation Foundation (WPF) sowie eine Einführung in das Konzept von Abhängigkeitseigenschaften.

Und schließlich enthält das SDK noch XAMLPad, ein Tool zum Bearbeiten von XAML-Code. Mit diesem Tool können Sie mit XAML in Echtzeit experimentieren.

Siehe auch

Konzepte

XAMLPad

XAML und benutzerdefinierte Klassen

Übersicht über Basiselemente

Strukturen in WPF

Weitere Ressourcen

Sprachfeatures des XAML-Namespace (x:)

XAML-definierte WPF-Namespaceerweiterungen

Inhaltsmodelle