Partager via


Guide de la syntaxe XAML

Nous expliquons les règles de syntaxe XAML et la terminologie qui décrit les restrictions ou les choix disponibles pour la syntaxe XAML. Vous trouverez cette rubrique utile si vous débutez avec le langage XAML, que vous souhaitez actualiser la terminologie ou les parties de la syntaxe, ou si vous êtes curieux de savoir comment fonctionne le langage XAML et souhaitez plus d’arrière-plan et de contexte.

XAML est XML

Le langage XAML (Extensible Application Markup Language) a une syntaxe de base qui s’appuie sur XML et, par définition, le code XAML valide doit être xml valide. Mais XAML possède également ses propres concepts de syntaxe qui étendent le code XML. Une entité XML donnée peut être valide en XML brut, mais cette syntaxe peut avoir une signification différente et plus complète en tant que CODE XAML. Cette rubrique explique ces concepts de syntaxe XAML.

Vocabulaires XAML

Une zone où XAML diffère de la plupart des utilisations XML est que le code XAML n’est généralement pas appliqué avec un schéma, tel qu’un fichier XSD. C’est parce que XAML est destiné à être extensible, c’est ce que signifie « X » dans l’acronyme XAML. Une fois le code XAML analysé, les éléments et les attributs que vous référencez en XAML sont censés exister dans une représentation du code de stockage, soit dans les types principaux définis par Windows Runtime, soit dans les types qui étendent ou sont basés sur Windows Runtime. La documentation du Kit de développement logiciel (SDK) fait parfois référence aux types qui sont déjà intégrés à Windows Runtime et qui peuvent être utilisés en XAML comme étant le vocabulaire XAML pour Windows Runtime. Microsoft Visual Studio vous aide à produire des marques valides dans ce vocabulaire XAML. Visual Studio peut également inclure vos types personnalisés pour l’utilisation XAML tant que la source de ces types est référencée correctement dans le projet. Pour plus d’informations sur les types XAML et personnalisés, consultez les espaces de noms XAML et le mappage d’espaces de noms.

Déclaration d’objets

Les programmeurs pensent souvent en termes d’objets et de membres, tandis qu’un langage de balisage est conceptualisé en tant qu’éléments et attributs. Dans le sens le plus simple, un élément que vous déclarez dans le balisage XAML devient un objet dans une représentation d’objet runtime de stockage. Pour créer un objet runtime pour votre application, vous déclarez un élément XAML dans le balisage XAML. L’objet est créé lorsque Windows Runtime charge votre code XAML.

Un fichier XAML possède toujours exactement un élément servant de racine, qui déclare un objet qui sera la racine conceptuelle d’une structure de programmation telle qu’une page ou le graphique d’objet de la définition d’exécution entière d’une application.

En termes de syntaxe XAML, il existe trois façons de déclarer des objets en XAML :

  • Directement, à l’aide de la syntaxe d’élément d’objet : elle utilise des balises d’ouverture et de fermeture pour instancier un objet en tant qu’élément de formulaire XML. Vous pouvez utiliser cette syntaxe pour déclarer des objets racines ou créer des objets imbriqués qui définissent des valeurs de propriété.
  • Indirectement, à l’aide de la syntaxe d’attribut : elle utilise une valeur de chaîne inline qui contient des instructions pour créer un objet. L’analyseur XAML utilise cette chaîne pour définir la valeur d’une propriété sur une valeur de référence nouvellement créée. La prise en charge est limitée à certains objets et propriétés courants.
  • Utilisation d’une extension de balisage.

Cela ne signifie pas que vous avez toujours le choix de n’importe quelle syntaxe pour la création d’objets dans un vocabulaire XAML. Certains objets peuvent être créés uniquement à l’aide de la syntaxe de l’élément objet. Certains objets peuvent être créés uniquement en étant initialement définis dans un attribut. En fait, les objets qui peuvent être créés avec l’élément objet ou la syntaxe d’attribut sont comparativement rares dans les vocabulaires XAML. Même si les deux formes de syntaxe sont possibles, l’une des syntaxes sera plus courante en matière de style. Il existe également des techniques que vous pouvez utiliser en XAML pour référencer des objets existants plutôt que de créer de nouvelles valeurs. Les objets existants peuvent être définis dans d’autres domaines de XAML, ou peuvent exister implicitement par le biais d’un comportement de la plateforme et de ses modèles d’application ou de programmation.

Déclaration d’un objet à l’aide de la syntaxe d’élément d’objet

Pour déclarer un objet avec une syntaxe d’élément d’objet, vous écrivez des balises comme suit : <objectName> </objectName>, où objectName est le nom de type de l’objet que vous souhaitez instancier. Voici l’utilisation de l’élément objet pour déclarer un objet Canvas :

<Canvas>
</Canvas>

Si l’objet ne contient pas d’autres objets, vous pouvez déclarer l’élément objet à l’aide d’une balise de fermeture automatique au lieu d’une paire ouvrante/fermante : <Canvas />

conteneurs

De nombreux objets utilisés comme éléments d’interface utilisateur, tels que Canvas, peuvent contenir d’autres objets. Il s’agit parfois de conteneurs. L’exemple suivant montre un conteneur Canvas qui contient un élément, un Rectangle.

<Canvas>
  <Rectangle />
</Canvas>

Déclaration d’un objet à l’aide de la syntaxe d’attribut

Étant donné que ce comportement est lié au paramètre de propriété, nous allons en parler plus dans les sections à venir.

Texte d’initialisation

Pour certains objets, vous pouvez déclarer de nouvelles valeurs à l’aide de texte interne utilisé comme valeurs d’initialisation pour la construction. En XAML, cette technique et cette syntaxe sont appelées texte d’initialisation. Conceptuellement, le texte d’initialisation est similaire à l’appel d’un constructeur qui a des paramètres. Le texte d’initialisation est utile pour définir les valeurs initiales de certaines structures.

Vous utilisez souvent une syntaxe d’élément objet avec du texte d’initialisation si vous souhaitez une valeur de structure avec un x :Key, afin qu’elle puisse exister dans un ResourceDictionary. Vous pouvez le faire si vous partagez cette valeur de structure entre plusieurs propriétés cibles. Pour certaines structures, vous ne pouvez pas utiliser la syntaxe d’attribut pour définir les valeurs de la structure : le texte d’initialisation est le seul moyen de produire une ressource CornerRadius, Épaisseur, GridLength ou Color utile et partageable.

Cet exemple abrégé utilise le texte d’initialisation pour spécifier des valeurs pour une épaisseur, dans ce cas en spécifiant des valeurs qui définissent à la fois gauche et droite sur 20, et haut et bas sur 10. Cet exemple montre l’épaisseur créée en tant que ressource clé, puis la référence à cette ressource. Pour plus d’informations sur le texte d’initialisation de l’épaisseur, consultez Épaisseur.

<UserControl ...>
  <UserControl.Resources>
    <Thickness x:Key="TwentyTenThickness">20,10</Thickness>
    ....
  </UserControl.Resources>
  ...
  <Grid Margin="{StaticResource TwentyTenThickness}">
  ...
  </Grid>
</UserControl ...>

Notez que certaines structures ne peuvent pas être déclarées en tant qu’éléments d’objet. Le texte d’initialisation n’est pas pris en charge et ne peut pas être utilisé comme ressources. Vous devez utiliser une syntaxe d’attribut pour définir les propriétés sur ces valeurs en XAML. Ces types sont : Duration, RepeatBehavior, Point, Rect et Size.

Définition de propriétés

Vous pouvez définir des propriétés sur des objets que vous avez déclarés à l’aide de la syntaxe d’élément d’objet. Il existe plusieurs façons de définir des propriétés en XAML :

  • À l’aide de la syntaxe d’attribut.
  • En utilisant la syntaxe de l’élément de propriété.
  • En utilisant la syntaxe d’élément où le contenu (texte interne ou éléments enfants) définit la propriété de contenu XAML d’un objet.
  • En utilisant une syntaxe de collection (qui est généralement la syntaxe de collection implicite).

Comme pour la déclaration d’objet, cette liste n’implique pas qu’aucune propriété puisse être définie avec chacune des techniques. Certaines propriétés ne prennent en charge qu’une des techniques. Certaines propriétés prennent en charge plusieurs formulaires ; Par exemple, il existe des propriétés qui peuvent utiliser la syntaxe de l’élément de propriété ou la syntaxe d’attribut. Ce qui est possible dépend à la fois de la propriété et du type d’objet utilisé par la propriété. Dans la référence de l’API Windows Runtime, vous verrez les utilisations XAML que vous pouvez utiliser dans la section Syntaxe . Parfois, il existe une autre utilisation qui fonctionnerait, mais serait plus détaillée. Ces utilisations détaillées ne sont pas toujours affichées, car nous essayons de vous montrer les meilleures pratiques ou les scénarios réels d’utilisation de cette propriété en XAML. Les instructions relatives à la syntaxe XAML sont fournies dans les sections Utilisation XAML des pages de référence pour les propriétés qui peuvent être définies en XAML.

Certaines propriétés sur les objets ne peuvent pas être définies en XAML par n’importe quel moyen et ne peuvent être définies qu’à l’aide du code. En règle générale, il s’agit de propriétés plus appropriées pour fonctionner dans le code-behind, et non en XAML.

Une propriété en lecture seule ne peut pas être définie en XAML. Même dans le code, le type propriétaire doit prendre en charge une autre façon de le définir, comme une surcharge de constructeur, une méthode d’assistance ou une prise en charge de propriété calculée. Une propriété calculée s’appuie sur les valeurs d’autres propriétés settables plus parfois un événement avec gestion intégrée ; ces fonctionnalités sont disponibles dans le système de propriétés de dépendance. Pour plus d’informations sur la façon dont les propriétés de dépendance sont utiles pour la prise en charge des propriétés calculées, consultez la vue d’ensemble des propriétés de dépendance.

La syntaxe de collection en XAML donne une apparence que vous définissez une propriété en lecture seule, mais en fait vous n’êtes pas. Consultez « Syntaxe de collection » plus loin dans cette rubrique.

Définition d’une propriété à l’aide de la syntaxe d’attribut

La définition d’une valeur d’attribut est le moyen classique par lequel vous définissez une valeur de propriété dans un langage de balisage, par exemple dans XML ou HTML. La définition d’attributs XAML est similaire à la façon dont vous définissez des valeurs d’attribut dans XML. Le nom de l’attribut est spécifié à n’importe quel point dans les balises suivant le nom de l’élément, séparé du nom de l’élément par au moins un espace blanc. Le nom de l’attribut est suivi d’un signe égal. La valeur d’attribut est contenue dans une paire de guillemets. Les guillemets peuvent être des guillemets doubles ou des guillemets simples tant qu’ils correspondent et placent la valeur. La valeur d’attribut elle-même doit être expressible sous forme de chaîne. La chaîne contient souvent des chiffres, mais en XAML, toutes les valeurs d’attribut sont des valeurs de chaîne jusqu’à ce que l’analyseur XAML soit impliqué et effectue une conversion de valeur de base.

Cet exemple utilise la syntaxe d’attribut pour quatre attributs pour définir les propriétés Name, Width, Height et Fill d’un objet Rectangle.

<Rectangle Name="rectangle1" Width="100" Height="100" Fill="Blue" />

Définition d’une propriété à l’aide de la syntaxe de l’élément de propriété

De nombreuses propriétés d’un objet peuvent être définies à l’aide de la syntaxe de l’élément de propriété. Un élément de propriété ressemble à ceci : <propriété> d’objet..

Pour utiliser la syntaxe des éléments de propriété, vous créez des éléments de propriété XAML pour la propriété que vous souhaitez définir. Dans le code XML standard, cet élément est simplement considéré comme un élément qui a un point dans son nom. Toutefois, en XAML, le point du nom de l’élément identifie l’élément en tant qu’élément de propriété, avec la propriété censée être membre d’un objet dans une implémentation de modèle objet de stockage. Pour utiliser la syntaxe de l’élément de propriété, il doit être possible de spécifier un élément d’objet afin de « remplir » les balises d’élément de propriété. Un élément de propriété aura toujours du contenu (élément unique, plusieurs éléments ou texte interne) ; il n’y a aucun point d’avoir un élément de propriété auto-fermant.

Dans la grammaire suivante, la propriété est le nom de la propriété que vous souhaitez définir et propertyValueAsObjectElement est un élément objet unique, qui est censé répondre aux exigences de type valeur de la propriété.

<object>

<propriété d’objet.>

propertyValueAsObjectElement

</propriété d’objet.>

</object>

L’exemple suivant utilise la syntaxe de l’élément de propriété pour définir le remplissage d’un rectangle avec un élément d’objet SolidColorBrush. (Dans le SolidColorBrush, Color est défini en tant qu’attribut.) Le résultat analysé de ce code XAML est identique à l’exemple XAML précédent qui définit Fill à l’aide de la syntaxe d’attribut.

<Rectangle
  Name="rectangle1"
  Width="100" 
  Height="100"
> 
  <Rectangle.Fill> 
    <SolidColorBrush Color="Blue"/> 
  </Rectangle.Fill>
</Rectangle>

Vocabulaires XAML et programmation orientée objet

Les propriétés et les événements tels qu’ils apparaissent en tant que membres XAML d’un type XAML Windows Runtime sont souvent hérités des types de base. Prenons cet exemple : <Button Background="Blue" .../>. La propriété Background n’est pas une propriété déclarée immédiatement sur la classe Button. Au lieu de cela, l’arrière-plan est hérité de la classe De contrôle de base. En fait, si vous examinez la rubrique de référence pour Button, vous verrez que les listes de membres contiennent au moins un membre hérité de chacune d’une chaîne de classes de base successives : ButtonBase, Control, FrameworkElement, UIElement, DependencyObject. Dans la liste Propriétés , toutes les propriétés et propriétés de collection en lecture-écriture sont héritées dans un sens de vocabulaire XAML. Les événements (comme les différents événements UIElement ) sont également hérités.

Si vous utilisez la référence Windows Runtime pour obtenir des instructions XAML, le nom d’élément affiché dans une syntaxe ou même dans un exemple de code est parfois pour le type qui définit initialement la propriété, car cette rubrique de référence est partagée par tous les types possibles qui l’héritent d’une classe de base. Si vous utilisez IntelliSense de Visual Studio pour XAML dans l’éditeur XML, IntelliSense et ses listes déroulantes effectuent un excellent travail de fusion de l’héritage et fournissent une liste précise d’attributs disponibles pour la définition une fois que vous avez démarré avec un élément objet pour une instance de classe.

Propriétés de contenu XAML

Certains types définissent l’une de leurs propriétés de sorte que la propriété active une syntaxe de contenu XAML. Pour la propriété de contenu XAML d’un type, vous pouvez omettre l’élément de propriété pour cette propriété lors de sa spécification en XAML. Vous pouvez également définir la propriété sur une valeur de texte interne en fournissant ce texte interne directement dans les balises d’élément d’objet du type propriétaire. Les propriétés de contenu XAML prennent en charge une syntaxe de balisage simple pour cette propriété et rendent le code XAML plus lisible par l’homme en réduisant l’imbrication.

Si une syntaxe de contenu XAML est disponible, cette syntaxe s’affiche dans les sections « XAML » de la syntaxe de cette propriété dans la documentation de référence windows Runtime. Par exemple, la page de propriétés Enfant pour Border affiche la syntaxe de contenu XAML au lieu de la syntaxe de l’élément de propriété pour définir la valeur Border.Child à objet unique d’une bordure, comme suit :

<Border>
  <Button .../>
</Border>

Si la propriété déclarée comme propriété de contenu XAML est le type d’objet ou est type String, la syntaxe de contenu XAML prend en charge le texte interne du modèle de document XML : chaîne entre les balises d’objet ouvrantes et fermante. Par exemple, la page de propriétés Texte pour TextBlock affiche la syntaxe de contenu XAML qui a une valeur de texte interne à définir Text, mais la chaîne « Text » n’apparaît jamais dans le balisage. Voici un exemple d’utilisation :

<TextBlock>Hello!</TextBlock>

Si une propriété de contenu XAML existe pour une classe, indiquée dans la rubrique de référence de la classe, dans la section « Attributes ». Recherchez la valeur de ContentPropertyAttribute. Cet attribut utilise un champ nommé « Name ». La valeur de « Name » est le nom de la propriété de cette classe qui est la propriété de contenu XAML. Par exemple, dans la page de référence de bordure , vous verrez ceci : ContentProperty(« Name=Child »).

Une règle de syntaxe XAML importante que nous devrions mentionner est que vous ne pouvez pas mélanger la propriété de contenu XAML et d’autres éléments de propriété que vous définissez sur l’élément. La propriété de contenu XAML doit être définie entièrement avant tous les éléments de propriété, ou entièrement après. Par exemple, il s’agit d’un code XAML non valide :

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

Syntaxe de collection

Toutes les syntaxes affichées jusqu’à présent définissent des propriétés sur des objets uniques. Toutefois, de nombreux scénarios d’interface utilisateur nécessitent qu’un élément parent donné puisse avoir plusieurs éléments enfants. Par exemple, une interface utilisateur pour un formulaire d’entrée nécessite plusieurs éléments de zone de texte, certaines étiquettes et peut-être un bouton « Envoyer ». Toutefois, si vous deviez utiliser un modèle objet de programmation pour accéder à ces plusieurs éléments, ils seraient généralement des éléments dans une propriété de collection unique, plutôt que chaque élément étant la valeur de propriétés différentes. XAML prend en charge plusieurs éléments enfants, ainsi que la prise en charge d’un modèle de collection de stockage classique en traitant les propriétés qui utilisent un type de collection comme implicite et effectuant une gestion spéciale pour tous les éléments enfants d’un type de collection.

De nombreuses propriétés de collection sont également identifiées comme propriété de contenu XAML pour la classe. La combinaison du traitement de collection implicite et de la syntaxe de contenu XAML est fréquemment vue dans les types utilisés pour la composition de contrôle, comme les panneaux, les vues ou les contrôles d’éléments. Par exemple, l’exemple suivant montre le xaml le plus simple possible pour composer deux éléments d’interface utilisateur homologue dans un StackPanel.

<StackPanel>
  <TextBlock>Hello</TextBlock>
  <TextBlock>World</TextBlock>
</StackPanel>

Mécanisme de syntaxe de collection XAML

Il peut d’abord apparaître que XAML active un « jeu » de la propriété de collection en lecture seule. En réalité, ce que XAML permet ici est d’ajouter des éléments à une collection existante. Le langage XAML et les processeurs XAML implémentant la prise en charge XAML s’appuient sur une convention dans les types de collection de stockage pour activer cette syntaxe. En règle générale, il existe une propriété de stockage telle qu’un indexeur ou une propriété Items qui fait référence à des éléments spécifiques de la collection. En règle générale, cette propriété n’est pas explicite dans la syntaxe XAML. Pour les collections, le mécanisme sous-jacent pour l’analyse XAML n’est pas une propriété, mais une méthode : en particulier, la méthode Add dans la plupart des cas. Lorsque le processeur XAML rencontre un ou plusieurs éléments d’objet dans une syntaxe de collection XAML, chaque objet de ce type est créé d’abord à partir d’un élément, puis chaque nouvel objet est ajouté pour la collection conteneur en appelant la méthode Add de la collection.

Lorsqu’un analyseur XAML ajoute des éléments à une collection, il s’agit de la logique de la méthode Add qui détermine si un élément XAML donné est un enfant d’élément autorisé de l’objet de collection. De nombreux types de collection sont fortement typés par l’implémentation de stockage, ce qui signifie que le paramètre d’entrée d’Add s’attend à ce que tout ce qui soit passé soit une correspondance de type avec le type de paramètre Add.

Pour les propriétés de collection, faites attention lorsque vous essayez de spécifier la collection explicitement en tant qu’élément d’objet. Un analyseur XAML crée un objet chaque fois qu’il rencontre un élément d’objet. Si la propriété de collection que vous essayez d’utiliser est en lecture seule, cela peut lever une exception d’analyse XAML. Utilisez simplement la syntaxe de collection implicite et vous ne verrez pas cette exception.

Quand utiliser la syntaxe d’attribut ou d’élément de propriété

Toutes les propriétés qui prennent en charge la définition en XAML prennent en charge la syntaxe d’attribut ou d’élément de propriété pour le paramètre de valeur directe, mais elles ne prennent pas en charge la syntaxe de manière interchangeable. Certaines propriétés prennent en charge l’une ou l’autre syntaxe et certaines propriétés prennent en charge des options de syntaxe supplémentaires comme une propriété de contenu XAML. Le type de syntaxe XAML pris en charge par une propriété dépend du type d’objet utilisé par la propriété comme type de propriété. Si le type de propriété est un type primitif, tel qu’un double (float ou décimal), un entier, booléen ou une chaîne, la propriété prend toujours en charge la syntaxe d’attribut.

Vous pouvez également utiliser la syntaxe d’attribut pour définir une propriété si le type d’objet que vous utilisez pour définir cette propriété peut être créé en traitant une chaîne. Pour les primitives, c’est toujours le cas, la conversion de type est intégrée à l’analyseur. Toutefois, certains autres types d’objets peuvent également être créés à l’aide d’une chaîne spécifiée comme valeur d’attribut, plutôt qu’un élément objet dans un élément de propriété. Pour que cela fonctionne, il doit y avoir une conversion de type sous-jacente, prise en charge par cette propriété particulière ou prise en charge généralement pour toutes les valeurs qui utilisent ce type de propriété. La valeur de chaîne de l’attribut est utilisée pour définir des propriétés importantes pour l’initialisation de la nouvelle valeur d’objet. Potentiellement, un convertisseur de type spécifique peut également créer différentes sous-classes d’un type de propriété commun, en fonction de la façon dont il traite de manière unique des informations dans la chaîne. Les types d’objets qui prennent en charge ce comportement auront une grammaire spéciale répertoriée dans la section syntaxe de la documentation de référence. Par exemple, la syntaxe XAML pour Brush montre comment une syntaxe d’attribut peut être utilisée pour créer une valeur SolidColorBrush pour n’importe quelle propriété de type Brush (et il existe de nombreuses propriétés brush dans le xaml Windows Runtime).

Logique et règles d’analyse XAML

Il est parfois informatif de lire le code XAML de la même façon qu’un analyseur XAML doit le lire : en tant qu’ensemble de jetons de chaîne rencontrés dans un ordre linéaire. Un analyseur XAML doit interpréter ces jetons sous un ensemble de règles qui font partie de la définition du fonctionnement du code XAML.

La définition d’une valeur d’attribut est le moyen classique par lequel vous définissez une valeur de propriété dans un langage de balisage, par exemple dans XML ou HTML. Dans la syntaxe suivante, objectName est l’objet que vous souhaitez instancier, propertyName est le nom de la propriété que vous souhaitez définir sur cet objet, et propertyValue est la valeur à définir.

<objectName propertyName="propertyValue" .../>

-or-

<objectName propertyName="propertyValue">

...<!--element children -->

</objectName>

L’une ou l’autre syntaxe vous permet de déclarer un objet et de définir une propriété sur cet objet. Bien que le premier exemple soit un élément unique dans le balisage, il existe en fait des étapes discrètes ici en ce qui concerne la façon dont un processeur XAML analyse ce balisage.

Tout d’abord, la présence de l’élément objet indique qu’un nouvel objet objectName doit être instancié. Une seule fois qu’une telle instance existe, la propriété propertyName de l’instance peut être définie dessus.

Une autre règle de XAML est que les attributs d’un élément doivent être définis dans n’importe quel ordre. Par exemple, il n’y a aucune différence entre <Rectangle Height="50" Width="100" /> et <Rectangle Width="100" Height="50" />. Quel ordre vous utilisez est une question de style.

Notez que les concepteurs XAML favorisent souvent les conventions de classement si vous utilisez des surfaces de conception autres que l’éditeur XML, mais vous pouvez modifier librement ce code XAML ultérieurement, pour réorganiser les attributs ou en introduire de nouveaux.

Propriétés jointes

XAML étend le code XML en ajoutant un élément de syntaxe appelé propriété jointe. Comme pour la syntaxe de l’élément de propriété, la syntaxe de propriété jointe contient un point et le point contient une signification spéciale pour l’analyse XAML. Plus précisément, le point sépare le fournisseur de la propriété jointe et le nom de la propriété.

En XAML, vous définissez les propriétés jointes à l’aide de la syntaxe AttachedPropertyProvider.PropertyName Voici un exemple de la façon dont vous pouvez définir la propriété jointe Canvas.Left en XAML :

<Canvas>
  <Button Canvas.Left="50">Hello</Button>
</Canvas>

Vous pouvez définir la propriété jointe sur les éléments qui n’ont pas de propriété de ce nom dans le type de stockage, et de cette façon ils fonctionnent un peu comme une propriété globale, ou un attribut défini par un autre espace de noms XML comme l’attribut xml :space .

Dans le code XAML Windows Runtime, vous verrez les propriétés jointes qui prennent en charge ces scénarios :

Pour plus d’informations, consultez la vue d’ensemble des propriétés jointes.

Valeurs littérales « { »

Étant donné que le symbole d’accolade ouvrant { est l’ouverture de la séquence d’extension de balisage, vous utilisez une séquence d’échappement pour spécifier une valeur de chaîne littérale commençant par « { ». La séquence d’échappement est «{} ». Par exemple, pour spécifier une valeur de chaîne qui est une accolade ouvrante unique, spécifiez la valeur d’attribut comme «{} { ». Vous pouvez également utiliser les guillemets alternatifs (par exemple, un ' dans une valeur d’attribut délimitée par « » ) pour fournir une valeur « { » en tant que chaîne.

Notez que « \} » fonctionne également s’il se trouve à l’intérieur d’un attribut entre guillemets.  

Valeurs d’énumération

De nombreuses propriétés de l’API Windows Runtime utilisent des énumérations comme valeurs. Si le membre est une propriété en lecture-écriture, vous pouvez définir une telle propriété en fournissant une valeur d’attribut. Vous identifiez la valeur d’énumération à utiliser comme valeur de la propriété à l’aide du nom non qualifié du nom de la constante. Par exemple, voici comment définir UIElement.Visibility en XAML : <Button Visibility="Visible"/>. Ici, la chaîne « Visible » est directement mappée à une constante nommée de l’énumération Visibility, Visible.

  • N’utilisez pas de formulaire qualifié, il ne fonctionnera pas. Par exemple, il s’agit d’un code XAML non valide : <Button Visibility="Visibility.Visible"/>.
  • N’utilisez pas la valeur de la constante. En d’autres termes, ne reposez pas sur la valeur entière de l’énumération qui existe explicitement ou implicitement selon la façon dont l’énumération a été définie. Bien qu’il semble fonctionner, il s’agit d’une mauvaise pratique en XAML ou dans le code, car vous vous appuyez sur ce qui pourrait être un détail d’implémentation temporaire. Par exemple, ne procédez pas comme suit : <Button Visibility="1"/>.

Remarque Dans les rubriques de référence pour les API qui utilisent XAML et utilisent des énumérations, cliquez sur le lien vers le type d’énumération dans la section Valeur de propriété de la syntaxe. Ce lien est lié à la page d’énumération dans laquelle vous pouvez découvrir les constantes nommées de cette énumération.

Les énumérations peuvent être flagwise, ce qui signifie qu’elles sont attribuées avec FlagsAttribute. Si vous devez spécifier une combinaison de valeurs pour une énumération au niveau de l’indicateur comme valeur d’attribut XAML, utilisez le nom de chaque constante d’énumération, avec une virgule (,) entre chaque nom et aucun espace intermédiaire. Les attributs flagwise ne sont pas courants dans le vocabulaire XAML Windows Runtime, mais ManipulationModes est un exemple où la définition d’une valeur d’énumération au niveau de l’indicateur dans XAML est prise en charge.

Interfaces en XAML

Dans de rares cas, vous verrez une syntaxe XAML où le type d’une propriété est une interface. Dans le système de type XAML, un type qui implémente cette interface est acceptable comme valeur lors de l’analyse. Il doit y avoir une instance créée de ce type disponible pour servir de valeur. Vous verrez une interface utilisée comme type dans la syntaxe XAML pour les propriétés Command et CommandParameter de ButtonBase. Ces propriétés prennent en charge les modèles de conception Model-View-ViewModel (MVVM) où l’interface ICommand est le contrat pour la façon dont les vues et les modèles interagissent.

Conventions d’espace réservé XAML dans la référence Windows Runtime

Si vous avez examiné l’une des sections Syntaxe des rubriques de référence pour les API Windows Runtime qui peuvent utiliser XAML, vous avez probablement vu que la syntaxe inclut quelques espaces réservés. La syntaxe XAML est différente de la syntaxe des composants C#, Microsoft Visual Basic ou Visual C++ (C++/CX), car la syntaxe XAML est une syntaxe d’utilisation. Il indique à votre utilisation éventuelle dans vos propres fichiers XAML, mais sans être sur-prescriptif sur les valeurs que vous pouvez utiliser. L’utilisation décrit généralement un type de grammaire qui mélange des littéraux et des espaces réservés, et définit certains des espaces réservés dans la section Valeurs XAML.

Lorsque vous voyez des noms de type / noms d’éléments dans une syntaxe XAML pour une propriété, le nom affiché est pour le type qui définit initialement la propriété. Toutefois, windows Runtime XAML prend en charge un modèle d’héritage de classe pour les classes basées sur DependencyObject. Vous pouvez donc souvent utiliser un attribut sur une classe qui n’est pas littéralement la classe de définition, mais dérive plutôt d’une classe qui a d’abord défini la propriété/l’attribut. Par exemple, vous pouvez définir Visibility en tant qu’attribut sur n’importe quelle classe dérivée UIElement à l’aide d’un héritage profond. Par exemple : <Button Visibility="Visible" />. Par conséquent, ne prenez pas le nom de l’élément affiché dans une syntaxe d’utilisation XAML trop littéralement ; la syntaxe peut être viable pour les éléments représentant cette classe, ainsi que pour les éléments qui représentent une classe dérivée. Dans les cas où il est rare ou impossible pour le type indiqué comme l’élément définissant d’être dans une utilisation réelle, ce nom de type est délibérément en minuscules dans la syntaxe. Par exemple, la syntaxe que vous voyez pour UIElement.Visibility est la suivante :

<uiElement Visibility="Visible"/>
-or-
<uiElement Visibility="Collapsed"/>

De nombreuses sections de syntaxe XAML incluent des espaces réservés dans la section « Utilisation » qui sont ensuite définies dans une section Valeurs XAML qui se trouve directement sous la section Syntaxe .

Les sections d’utilisation XAML utilisent également différents espaces réservés généralisés. Ces espaces réservés ne sont pas redéfinis chaque fois dans les valeurs XAML, car vous devinerez ou finirez par apprendre ce qu’ils représentent. Nous pensons que la plupart des lecteurs seraient fatigués de les voir dans les valeurs XAML de nouveau et de nouveau, donc nous les avons laissés hors des définitions. Pour référence, voici une liste de certains de ces espaces réservés et de ce qu’ils signifient dans un sens général :

  • objet : théoriquement toute valeur d’objet, mais souvent pratiquement limitée à certains types d’objets tels qu’un choix de chaîne ou d’objet, et vous devez vérifier les remarques sur la page de référence pour plus d’informations.
  • propriété d’objet : la propriété d’objet en combinaison est utilisée pour les cas où la syntaxe affichée est la syntaxe d’un type qui peut être utilisé comme valeur d’attribut pour de nombreuses propriétés. Par exemple, l’utilisation de l’attribut Xaml indiquée pour Brush inclut : <object property="prédéfiniColorName"/>
  • eventhandler : il s’agit de la valeur d’attribut pour chaque syntaxe XAML affichée pour un attribut d’événement. Ce que vous fournissez ici est le nom de la fonction d’une fonction de gestionnaire d’événements. Cette fonction doit être définie dans le code-behind de la page XAML. Au niveau de la programmation, cette fonction doit correspondre à la signature déléguée de l’événement que vous gérez, ou votre code d’application ne sera pas compilé. Mais c’est vraiment une considération de programmation, pas une considération XAML, donc nous n’essayons pas d’indiquer quoi que ce soit sur le type de délégué dans la syntaxe XAML. Si vous souhaitez savoir quel délégué vous devez implémenter pour un événement, c’est dans la section Informations sur l’événement de la rubrique de référence de l’événement, dans une ligne de table étiquetée Délégué.
  • enumMemberName : illustré dans la syntaxe d’attribut pour toutes les énumérations. Il existe un espace réservé similaire pour les propriétés qui utilisent une valeur d’énumération, mais il préfixe généralement l’espace réservé avec un indicateur du nom de l’énumération. Par exemple, la syntaxe indiquée pour FrameworkElement.FlowDirection est <frameworkElementFlowDirection="flowDirectionMemberName"/>. Si vous êtes sur l’une de ces pages de référence de propriété, cliquez sur le lien vers le type d’énumération qui apparaît dans la section Valeur de propriété, en regard du texte Type :. Pour la valeur d’attribut d’une propriété qui utilise cette énumération, vous pouvez utiliser n’importe quelle chaîne répertoriée dans la colonne Membre de la liste Membres .
  • double, int, string, bool : il s’agit de types primitifs connus du langage XAML. Si vous programmez en C# ou Visual Basic, ces types sont projetés vers des types équivalents Microsoft .NET tels que Double, Int32, String et Boolean, et vous pouvez utiliser n’importe quel membre sur ces types .NET lorsque vous utilisez vos valeurs définies par XAML dans le code-behind .NET. Si vous programmez à l’aide de C++/CX, vous allez utiliser les types primitifs C++, mais vous pouvez également considérer ces équivalents aux types définis par l’espace de noms Platform, par exemple Platform ::String. Il y aura parfois des restrictions de valeur supplémentaires pour des propriétés particulières. Toutefois, ces restrictions s’appliquent généralement aux utilisations de code et aux utilisations XAML dans une section De valeur de propriété ou remarques.

Conseils et astuces, notes sur le style

  • Les extensions de balisage en général sont décrites dans la vue d’ensemble principale du code XAML. Mais l’extension de balisage qui a le plus d’impact sur les instructions fournies dans cette rubrique est l’extension de balisage StaticResource (et ThemeResource associée). La fonction de l’extension de balisage StaticResource consiste à activer le factoring de votre code XAML en ressources réutilisables provenant d’un ResourceDictionary XAML. Vous définissez presque toujours des modèles de contrôle et des styles associés dans un ResourceDictionary. Vous définissez souvent les parties plus petites d’une définition de modèle de contrôle ou d’un style spécifique à l’application dans un ResourceDictionary également, par exemple un SolidColorBrush pour une couleur que votre application utilise plusieurs fois pour différentes parties de l’interface utilisateur. À l’aide d’un StaticResource, toute propriété qui nécessiterait autrement une utilisation d’un élément de propriété à définir peut désormais être définie dans la syntaxe d’attribut. Mais les avantages de factoriser XAML pour la réutilisation vont au-delà de simplifier simplement la syntaxe au niveau de la page. Pour plus d’informations, consultez les références de ressources ResourceDictionary et XAML.
  • Vous verrez plusieurs conventions différentes pour la façon dont les flux d’espace blanc et de ligne sont appliqués dans des exemples XAML. En particulier, il existe différentes conventions pour décomposer les éléments d’objet qui ont un grand nombre d’attributs différents définis. C’est juste une question de style. L’éditeur XML de Visual Studio applique certaines règles de style par défaut lorsque vous modifiez XAML, mais vous pouvez les modifier dans les paramètres. Il existe un petit nombre de cas où l’espace blanc dans un fichier XAML est considéré comme significatif ; pour plus d’informations, consultez XAML et espace blanc.