Bien souvent, le rendu
graphique d'une application est fonction de donnée de type simple."Rendu
graphique" est peut-être un bien grand mot, par conséquent, prenons un
exemple concret qui va vous permettre de comprendre l'intérêt des converters.
Imaginons que vous
desiriez afficher la liste des morceaux de musique disponible dans votre
médiathèque et que cette liste contienne le titre et la note de chaque morceaux.
Afficher une note sous la forme "4/5" n'est pas très esthétique et ne
permet pas de retrouver d'un coup d'oeil les morceaux les mieux notés. Par
conséquent vous désirez représenter la note par des étoiles.
Vous allez donc pouvoir
utiliser un converter lors du binding pour convertir la note originale en
étoile.
La source
Admettons la classe
suivante :
public class Mp3
{
private string _name;
private int _mark = 0;
public Mp3(string name)
{
this.Name = name;
}
public string Name
{
get { return _name; }
set { _name = value; }
}
public int Mark
{
get { return _mark; }
set { _mark = value; }
}
}
Le converter
A l’endroit où vous
voulez afficher la note, au lieu de mettre un Label, TextBlock ou autre, vous
allez plutôt placer une Image. Le principe va alors être de modifier le Path de
l’image en fonction de la note du Mp3. Il serait ici possible de ne pas
utiliser de converter pour faire cela, en nommant vos image 1.jpg, 2.jpg, 3.jpg
etc par exemple. Mais le but ici est de vous montrer comment utiliser des
converter et non de faire des choses très complexes.
Le converter que nous
devons coder est une classe qui doit implémenter l’interface IValueConverter. Celle-ci
impose que l'on implémente deux fonctions qui convertissent la valeur du
Binding (un int ici) en valeur voulue (de type ImageSource ici) et inversement.
Si vous voulez faire un binding dans les deux sens, il faudra implémenter le
code pour ces deux fonctions.
Voici le code :
public class MarkToImageConverter :
IValueConverter
{
public object Convert(object value, Type targetType, object
parameter, System.Globalization.CultureInfo culture)
{
BitmapImage
bmp = new BitmapImage();
bmp.BeginInit();
bmp.UriSource = new Uri("pack://application:,,,/MyApplication;component/”
+ (int)value);
bmp.EndInit();
return bmp;
}
public object ConvertBack(object value, Type targetType,
object parameter, System.Globalization.CultureInfo culture)
{throw new Exception("The method or operation is not
implemented.");}
}
L’object value est le
paramètre qui est lié à l’image, pour nous c’est la note du Mp3, donc un int.
Le xaml: binding et appel du converter
Maintenant que nous avons
le converter et le type source, il ne reste plus qu’à lier le tout.
La première chose va être
de déclarer le converter et de l’identifier :
<Window.Resources>
…
<MyApplication:MarkToImageConverter
x:Key="MarkToImage"/>
Et maintenant le code de l’Image:
<Image Source="{Binding
Path=Mark, Converter={StaticResource MarkToImage}}"
Height="32" Width="32" Margin="2,2,2,2"/>
Maintenant que le lien entre l’Image , le converter et la note du Mp3 est
établi il ne va plus que vous rester à générer ces images et à les alimenter (voir
la partie Binding pour cela).
WPF est une des briques
du framework .Net 3.0 dont on parle le plus en ce moment, notamment car son
impact dans les futurs développements d’applications Windows sera très
important. Le mot « révolution » est bien souvent employé lorsqu’on
évoque WPF, mais qu’en est-il vraiment ? Que propose WPF ? Quel
impact aura WPF sur la conception et le développement de nos futures
applications ? C’est ce à quoi nous allons tenter de répondre dans cet
article. 
Après le WPF, venons en
au WWF, le Windows Workflow Foundation. Autant lorsqu’on parlait de WPF on
comprenait rapidement qu’il s’agissait de présentation et donc d’interface,
autant là, sans explication, on reste à se demander de quoi il s’agit, ce que
ça propose et pour qui c’est fait tellement le mot workflow est devenu vague,
car employé à toutes les sauces. Cet article va donc tenter de répondre à ces
questions.
Les worflows événementiels
sont des automates à états finis, plus utiles lors d’interactions humaines
(comme le suivi d’une commande). Dans un automate à états finis, l’enchaînement
des opérations n’est pas déterministe, le workflow est composé de l’ensemble
des états possibles ainsi que des règles de transition d’un état à l’autre.
