www.infkoffler.com - Site de cours d'informatique

Accueil

Java Standard Edition

Java EE 5

Visual Basic .Net 2005

Cours Javascript - DOM - DHTML

Nouveautés sur le site

Contacts

Accueil > Visual Studio 2008 > Windows Presentation Foundation(WPF)

____________________________________________________________________________________________________

Connexion

WPF XAML

Le langage XAML est de la programmation déclarative. XAML = eXtensible Application Markup Langage.

1 composant graphique = 1 balise
Exemple <button> </button>

I) Comprendre le système du xaml

a) Raisonnement à partir du xaml : première façon de voir les choses

- Avec le XAML, on arrive à décrire chaque composant graphique complètement. Aussi bien qu’on y arrivait avec le c#. Donc le besoin de pouvoir décrire nos composants graphiques est comblé, peut importe que le code utilisé soit du code XAML ou du code c#.

- Maintenant reste le besoin de pouvoir accéder en c# aux attributs de nos composants graphiques, afin de pouvoir les modifier ou les lire. Il y a donc une nécessité d’avoir un moyen de pouvoir, en c#, lire ou modifier les valeurs des attributs xaml( pour modification ou lecture). Une solution serait de pouvoir récupérer un objet pour chaque composant graphique. De plus, le xaml ne nous suffit plus, car il y a besoin d’avoir un objet « vivant », avec des propriétés qui peuvent varier au cours de sa vie. Or seul un objet en mémoire peut répondre à ça. C’est le système utilisé par WPF : WPF construit en début d’application des objets correspondant à la description xaml. Et ce seront ces objets que le programmeur manipulera.

Nos deux besoins étant comblés par le système mis en place avec xaml et WPF, on en conclut que ce système est acceptable.

b) Raisonnement à partir du c# : deuxième façon de voir les choses, l’approche objet

Ce raisonnement me semble être le meilleur et le plus naturel, et peut-être bien le seul !

On peut faire le raisonnement dans l’autre sens, et se dire qu’une fenêtre est toujours un objet c#, comme avec les Windows Forms. Et que les contrôles de la fenêtre sont des objets, comme avec les Windows Forms. Seul change l’initialisation des attributs des contrôles, qui est faite directement à partir des données du fichier XAML, au lieu d’écrire les valeurs dans des lignes de code c#. A partir de ce raisonnement, on se rend compte de ce qui suit :

b.2) Différence avec les Windows forms

Par rapport aux Windows Forms de Visual Studio 2005, on remarque que la différence est que l’initialisation des propriétés des contrôles de la fenêtre ne se trouve plus dans l’initialize_component, mais dans le fichier xaml. Ce qui a, bien entendu, de multiples avantages, comme de séparer la partie présentation du reste.

II) Les contrôles WPF

II.1) La propriété Content( « Content » = "contenu" en français)

Une innovation des contrôles WPF est qu’on peut mettre, à l’intérieur, ce qu’on a envie d’y mettre. Cela peut être un autre contrôle WPF.
Vous me direz que cela était déjà possible avec les Windows forms, que le contrôle button, par exemple, possède la propriété image pour pouvoir placer une image dans un bouton. Ceci est exact, mais parce que la propriété a été pensée auparavant par les concepteurs de la classe button. Il suffit que vous ayez besoin de mettre, dans votre bouton, un contrôle qu’il n’était pas prévu de mettre à l’intérieur, et alors ceci est impossible à faire ! On se retrouvait donc limité quant au choix de l’objet à mettre à l’intérieur. En résumé, c’était possible, mais c’était prévu en « statique », c'est-à-dire avec une propriété prévue auparavant.
La solution serait d’avoir une propriété dynamique, qui contiendrait l’objet qu’on veut mettre à l’intérieur, et qui pourrait contenir, bien entendu, n’importe quel type d’objet. Le type Object serait donc le bienvenu pour cette propriété.

Et bien, c’est exactement ce que fait la nouvelle propriété Content des contrôles WPF ! Cette propriété est de type object. On y met l’objet qu’on veut y mettre à l’intérieur de notre contrôle. Le contrôle WPF button possède, par exemple, une propriété Content, dans laquelle on peut mettre, par exemple, une image( pour reprendre l’exemple ci-dessus).

La propriété Content permet donc d’avoir des contrôles vraiment personnalisables, et vient combler cette lacune des contrôles Windows Forms.

Remarque : par défaut, la propriété Content contient une string qui est le texte affiché dans le contrôle, par exemple le texte affiché dans le bouton. Utilisée par défaut, elle est donc similaire à la propriété text des Windows Forms. Et la signification de « Content » est ici respectée, car le texte à l’intérieur, c’est bien un contenu !(ici, le contenu du contrôle est un objet string !).

Remarque : en XAML, pour décrire le Content, il y a deux façons de faire.
Si le Content est une string, on ajoute simplement l’attribut Content= « monText » dans la balise Button( par exemple).

<Button Height="23" Margin="120,33,83,0" Name="button2" VerticalAlignment="Top" Content="Button">
</Button>

Une autre façon de faire, utilisée quand le contenu est plus complexe( une image, par exemple), est d’écrire le contenu entre la balise ouvrante et fermante du contrôle. Remarque : c’est applicable aussi pour le cas d’une string.
On peut remarquer que la logique du XHTML est respectée, car en XHTML, quand on veut afficher quelque chose, on le place aussi entre les deux balises.

<Button Margin="96,78,52,110" Name="button1" OpacityMask="YellowGreen">
<Image Margin="108,23,70,0" Name="image1" Stretch="Fill" Height="33" VerticalAlignment="Top" Width="10" />
</Button>

Remarque : un contrôle pouvant contenir lui-même un autre contrôle, les contrôles sont vraiment personnalisables à volonté. Car on peut faire ce qu’on veut, par conséquent : un contrôle qui contient un contrôle, qui lui-même contient un autre contrôle, etc…

Tout est donc permis. La seule extension possible serait d’avoir autant de propriétés Content qu’on veut, pour un même contrôle( tout n’est donc pas permis, on ne peut pas mettre 2 contrôles, par exemple, dans un contrôle). Une solution plus intelligente serait d'avoir une seule propriété qui serait une collection d'objets Content.

Autre remarque sur le Panel de Windows Forms : les conteneurs de Windows Forms peuvent effectivement contenir un contrôle( et même autant qu’on veut). Mais disposer de conteneurs n’est pas aussi puissant que l’apport de la propriété Content de WPF, car un conteneur est un contrôle particulier, dédié à cela. Or on voulait pouvoir mettre un contrôle à l’intérieur de N’IMPORTE QUEL CONTROLE !

II.2) Le contrôle Grid

Le contrôle Grid est comme la balise table html.
Exemple( à mettre dans une balise <window>, bien entendu) :

<Window x:Class="testWpf.Window1"

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

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

Title="Window1" Height="300" Width="300">

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<Grid.ColumnDefinitions>

</Grid.ColumnDefinitions>

<TextBlock Grid.Row="1" Grid.Column="0">Prenom:</TextBlock>

</Grid>

</Window>

Tout est dans une balise <Grid>, la balise <Grid> ressemble à la balise <table> de XHTML.
On remarque une balise <Grid.RowDefinitions>, qui ressemble à la balise <tr> de xhtml. La seule différence avec la balise <tr> est que les balises équivalentes à <td>( les balises xaml Grid.ColumnDefinitions) ne se trouvent pas imbriquées dans la balise <Grid.RowDefinitions>. D’ailleurs c’est logique, car les deux balises <Grid.RowDefinitions> et <Grid.ColumnDefinitions> seront toutes les deux des attributs c# de l’objet c# Grid. Donc il est logique qu’elles soient au même niveau. Je pense qu’il est bon de garder un raisonnement objet c#, car finalement c’est la réalité de l’implémentation utilisée en WPF.
XAML dispose de la fonctionnalité « Property element syntax »( = « syntaxe d’élément propriété »). Cela étend le langage xml, et permet de pouvoir déclarer les attributs aussi sous forme de balise, et non plus uniquement sous la forme classique des attributs des balises xml.
Plus concrètement, le <Grid.ColumnDefinitions> est l’attribut ColumnDefinitions de la Grid. On remarque qu’on doit mettre Grid suivi d’un point « . » derrière. On peut bien s’apercevoir, dans la fenêtre « properties