Dot.Blog

C# 4.0 : les nouveautés du langage

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 10 Nov 2009 05:25:55 +0200

Visual Studio 2010 beta 2 est maintenant accessible au public et il devient donc possible de vous parler des nouveautés sans risque de violer le NDA qui courrait jusqu’à lors pour les MVP et autres early testers de ce produit.

Les évolutions du langage commencent à se tasser et la mouture 4.0 est assez loin des annonces fracassantes qu’on a pu connaître avec l’arrivée des génériques ou des classes statiques et autres nullables de C# 2.0, ni même avec LINQ ou les expressions Lambda de C# 3.0.

Pour la version 4 du langage on compte pour l’instant peu d’ajouts (le produit ne sortira qu’en 2010 et que d’autres features pourraient éventuellement apparaître). On peut regrouper les 3 principales nouveautés ainsi :

Les type dynamiques (dynamic lookup)
Les paramètres nommés et les paramètres optionnels
Covariance et contravariance

Paramètres optionnels

Il est en réalité bien étrange qu’il ait fallu attendre 4 versions majeures de C# pour voir cette syntaxe de Delphi refaire surface tellement son utilité est évidente.
De quoi s’agit-il ? Vous avez tous écrits du code C# du genre :

   1:  MaMethode(typeA param1, typeB param2, typeC param3) …;

   2:  MaMethode(typeA param1, typeB param2) { MaMethode(param1, param2, null) }

   3:  MaMethode(typeA param1) { MaMethode(param1, null) }

   4:  MaMethode() { MaMethode(null) }

Et encore cela n’est qu’un exemple bien court. Des librairies entières ont été écrites en C# sur ce modèle afin de permettre l’appel à une même méthode avec un nombre de paramètres variable. Le Framework lui-même est écrit comme cela.
Bien sûr il existe “params” qui autorise dans une certaine mesure une écriture plus concise, mais dans une certaine mesure seulement. Dans l’exemple ci-dessus le remplacement des valeurs manquantes par des nulls est une simplification. Dans la réalité les paramètres ne sont pas tous des objets ou des nullables. Dans ces cas là il faut spécifier des valeurs bien précises aux différents paramètres omis. Chaque valeur par défaut se nichant dans le corps de chacune des versions de la méthode, pour retrouver l’ensemble de ceux-ci il faut donc lire toutes les variantes et reconstituer de tête la liste. Pas très pratique.

Avec C# 4.0 cette pratique verbeuse et inefficace prend fin. Ouf !
Il est donc possible d’écrire une seule version de la méthode comme cela :

   1:  MaMethode(bool param1=false, int param2=25, MonEnum param3 = MonEnum.ValeurA)  …

Grâce à cette concision l’appel à “MaMethode(true)” sera équivalente à “MaMethode(true, 25, MonEnum.ValeurA)”. Le premier paramètre est fixé par l’appelant (c’est un exemple), mais les deux autres étant oubliés ils se voient attribuer automatiquement leur valeur par défaut.

Pas de surcharges inutiles de la méthode, toutes les valeurs par défaut sont accessibles dans une seule déclaration. Il reste encore quelques bonnes idées dans Delphi que Anders pourraient reprendre comme les indexeurs nommés ou les if sans nécessité de parenthèses systématiques. On a le droit de rêver :-)

Comme pour se faire pardonner d’avoir attendu 4 versions pour ressortir les paramètres par défaut de leur carton, C# 4.0 nous offre un petit supplément :

Les paramètres nommés

Les paramètres optionnels c’est sympa et pratique, mais il est vrai que même sous Delphi il restait impossible d’écrire du code tel quel “MaMethode(true,,MonEnum.ValeurA)”. En effet, tout paramètre doit recevoir une valeur et les paramètres “sautés” ne peuvent être remplacés par des virgules ce qui rendrait le code totalement illisible. C# 4.0 n’autorise pas plus ce genre de syntaxe, mais il offre la possibilité de ne préciser que quelques uns des paramètres optionnels en donnant leur nom.

La technique est proche de celle utilisée dans les initialiseurs de classe qui permettent d’appeler un constructeur éventuellement sans paramètre et d’initialiser certaines propriétés de l’instance en les nommant. Ici c’est entre les parenthèses de la méthode que cela se jouera. Pour suivre notre exemple précédent, si on veut ne fixer que la valeur de “param3” il suffit d’écrire :

   1:  MaMethode(param3 : MonEnum.ValeurZ);

de même ces syntaxes seront aussi valides :

   1:  MaMethode(true,param3:MonEnum.ValeurX);

   2:  MaMethode(param3:MonEnum.ValeurY,param1:false);

En effet, l’ordre n’est plus figé puisque les noms lèvent toute ambigüité. Quant aux paramètres omis, ils seront remplacés par leur valeur par défaut.

Voici donc une amélioration syntaxique qui devrait simplifier beaucoup le code de nombreuses librairies, à commencer par le Framework lui-même !

Dynamique rime avec Polémique

Autre nouveauté de C# 4.0, les types dynamiques. Aie aie aie…

Dynamique. C’est un mot qui fait jeune, sautillant, léger. Hélas. Car cela ne laisse pas présager du danger que représente cette extension syntaxique ! La polémique commence ici et, vous l’aurez compris, je ne suis pas un fan de cette nouveauté :-)

Techniquement et en deux mots cela permet d’écrire “MaVariable.MethodeMachin()” sans être sûr que l’instance pointée par MaVariable supporte la méthode MethodeMachin(). Et ça passe la compilation sans broncher. Si çà pète à l’exécution, il ne faudra pas venir se plaindre. Le danger du nouveau type “dynamic” est bien là. Raison de mes réticences…

Si on essaye d’être plus positif il y a bien sûr des motivations réelles à l’implémentation des dynamiques. Par exemple le support par .NET des langages totalement dynamiques comme Python et Ruby (les dynamique de C# 4 s’appuient d’ailleurs sur le DLR), même si ces langages sont plus des gadgets amusants que l’avenir du développement (avis personnel). Les dynamiques simplifient aussi l’accès aux objets COM depuis IDispatch, mais COM n’est pas forcément non plus l’avenir de .NET (autre avis personnel).

Les deux autres emplois des dynamiques qui peuvent justifier leur existence sont l’accès simplifié à des types .NET au travers de la réflexion (pratique mais pas indispensable) ou bien des objets possédant une structure non figée comme les DOM HTML (pratique mais à la base de pas mal de code spaghetti).

Bref, les dynamiques ça peut être utile dans la pratique, mais ce n’est pas vraiment une nouvelle feature améliorant C# (comme les autres ajouts jusqu’à maintenant). Le danger de supporter un tel type est-il compensé par les quelques avantages qu’il procure ? C’est là que dynamique rime avec polémique !
Pour moi la réponse est non, mais je suis certain que ceux qui doivent jongler avec du COM ou des DOM Html penseront le contraire.

J’arrête de faire le grognon pour vous montrer un peu mieux la syntaxe. Car malgré tout le dynamisme n’est pas une invitation au chaos. Enfin si. Mais un chaos localisé. C’est à dire que l’appel à une méthode non existante reste impossible partout, sauf pour un objet déclaré avec le nouveau type “dynamic” :

   1:  dynamic x;

   2:  x = Machin.ObtientObjetDynamique();

   3:  x.MethodeA(85); // compile dans tous les cas

4:

   5:  dynamic z = 6; // conversion implicite

   6:  int i = z; // sorte de unboxing automatique

7:

Bien entendu le “dynamisme” est total : cela fonctionne sur les appels de méthodes autant que sur les propriétés, les délégués, les indexeurs, etc.

Le compilateur va avoir pour charge de collecter le maximum d’information sur l’objet dynamique utilisé (comment il est utilisé, ses méthodes appelées…), charge au runtime du Framework de faire le lien avec la classe de l’instance qui se présentera à l’exécution. C’est du late binding avec tout ce qui va avec notamment l’impossibilité de contrôler le code à la compilation.

A vous de voir, mais personnellement je déconseille fortement l’utilisation des dynamiques qui sont comme un gros interrupteur ajouté en façade de C# “Langage Fortement On/Off”. Restez dans le mode “On” et ne passez jamais en mode “Off” !

Covariance et Contravariance ou le retour de l’Octothorpe

J’adore le jargon de notre métier. “Comment passer pour un hasbeen en deux secondes à la machine à café” est une mise en situation comique que j’utilise souvent, certainement influencé par mon passé dans différentes grosses SSII parisiennes et par la série Caméra Café de M6…
Ici vous aurez l’air stupide lorsque quelqu’un lancera “Alors t’en penses quoi de la contravariance de C#4.0 ?”… L’ingé le plus brillant qui n’a pas lu les blogs intéressants la veille sera dans l’obligation de plonger le nez dans son café et de battre en retraire piteusement, prétextant un truc urgent à finir…

Covariance et contravariance sont des termes académiques intimidants. Un peu comme si on appelait C# “C Octothorpe”. On aurait le droit. Octothorpe est l’un des noms du symbole #. Mais franchement cela serait moins sympathique que “do dièse” (C# est la notation de do dièse en américain, à condition de prononcer le # comme “sharp” et non “square” ou “octothorpe”).

Un support presque parfait sous C# 1 à 3

Un peu comme monsieur Jourdain faisait de la prose sans le savoir, la plupart d’entre nous a utilisé au moins la covariance en C# car il s’agit de quelque chose d’assez naturel en programmation objet et que C# le supporte pour la majorité des types. D’ailleurs la covariance existe depuis le Framework 2.0 mais pour certains cas (couverts par C# 4.0) il aurait fallu émettre directement du code IL pour s’en servir.

C# 4.0 n’ajoute donc aucune nouvelle fonctionnalité ou concept à ce niveau, en revanche il comble une lacune des versions 1 à 3 qui ne supportaient pas la covariance et la contravariance pour les délégués et les interfaces dans le cadre de leur utilisation avec les génériques. Un cas bien particulier mais devant lequel on finissait pas tomber à un moment ou un autre.

Un besoin simple

C# 4.0 nous assure simplement que les choses vont fonctionner comme on pourrait s’y attendre, ce qui n’était donc pas toujours le cas jusqu’à lors.

Les occasions sont rares où interfaces et délégués ne se comportent pas comme prévu sous C#, très rares. Mais cela peut arriver. Avec C# 4.0 ce sont ces situations rares qui sont supprimées. De fait on pourrait se dire qu’il n’y a rien à dire sur cette nouveauté de C# 4.0 puisqu’on utilisait la covariance et la contravariance sans s’en soucier et que la bonne nouvelle c’est qu’on va pouvoir continuer à faire la même chose !

Mais s’arrêter là dans les explications serait un peu frustrant.

Un exemple pour mieux comprendre

Supposons les deux classes suivantes :

   1:  class Animal{ }

   2:  class Chien: Animal{ }

La seconde classe dérive de la première. Imaginons que nous écrivions maintenant un délégué définissant une méthode retournant une instance d’un type arbitraire :

   1:  delegate T MaFonction<T>();

Pour retourner une instance de la classe Chien nous pouvons écrire :

   1:  MaFonction<Chien> unChien = () => new Chien();

Vous noterez l’utilisation d’une expression Lambda pour définir le délégué. Il s’agit juste d’utiliser la syntaxe la plus concise. On pourrait tout aussi bien définir d’abord une fonction retournant un Chien, lui donner un nom, puis affecter ce dernier à la variable “unChien” comme dans le code ci-dessous :

   1:  public Chien GetChien()

   2:  {

   3:      return new Chien();

   4:  }

5:

   6:  MaFonction<Chien> unChien = GetChien; // sans les () bien sur !

7:

Partant de là, il est parfaitement naturel de se dire que le code suivant est valide :

   1:  MaFonction<Animal> animal = unChien;

En effet, la classe Chien dérivant de Animal, il semble légitime de vouloir utiliser le délégué de cette façon. Hélas, jusqu’à C# 3.0 le code ci-dessus ne compile pas.

La Covariance

La covariance n’est en fait que la possibilité de faire ce que montre le dernier exemple de code. C# 4.0 introduit les moyens d’y arriver en introduisant une nouvelle syntaxe. Cette dernière consiste tout simplement à utiliser le mot clé “out” dans la déclaration du délégué:

   1:  delegate T MaFonction<out T>();

Le mot clé “out” est déjà utilisé en C# pour marquer les paramètres de sortie dans les méthodes. Mais il s’agit bien ici d’une utilisation radicalement différente. Pourquoi “out” ? Pour marquer le fait que le paramètre sera utilisé en “sortie” de la méthode.

La covariance des délégués sous C# 4.0 permet ainsi de passer un sous-type du type attendu à tout délégué qui produit en sortie (out) le type en question.

Si vous pensez que tout cela est bien compliqué, alors attendez deux secondes que je vous parle de contravariance !

La Contravariance

Si la covariance concerne les délégués et les interfaces utilisés avec les types génériques dans le sens de la sortie (out), et s’il s’agit de pouvoir utiliser un sous-type du type déclaré, ce qui est très logique en POO, la contravariance règle un problème inverse : autoriser le passage d’un super-type non pas en sortie mais en entrée d’une méthode.

Un exemple de contravariance

Pas de panique ! un petit exemple va tenter de clarifier cette nuance :

   1:  delegate void Action1<in T>(T a);

2:

   3:  Action1<Animal> monAction = (animal) => { Console.WriteLine(animal); };

   4:  Action1<Chien> chien1 = monAction;

Bon, ok. Paniquez. !!!

Ici un délégué est défini comme une méthode ayant un paramètre de type arbitraire. Le mot clé “in” remplace “out” de la covariance car le paramètre concerné est fourni en entrée de la méthode (in).

La plupart des gens trouve que la contravariance est moins intuitive que la covariance, et une majorité de développeurs trouve tout cela bien complexe. Si c’est votre cas vous êtes juste dans la norme, donc pas de complexe :-)

La contravariance se définit avec le mot clé “in” simplement parce que le type concerné est utilisé comme paramètre d’entrée. Encore une fois cela n’a rien à voir avec le sens de “in” dans les paramètres d’entrée des méthodes. Tout comme “out” le mot clé “in” est utilisé ici dans un contexte particulier, au niveau de la déclaration d’un type générique dans un délégué.

Avec la contravariance il est donc possible de passer un super-type du type déclaré. Cela semble contraire aux habitudes de la POO (passer un sous-type d’un type attendu est naturel mais pas l’inverse). En réalité la contradiction n’est que superficielle. Dans le code ci-dessus on s’aperçoit qu’en réalité “monAction” fonctionne avec n’importe quelle instance de “Animal”, un Chien étant un Animal, l’assignation est parfaitement légitime !

M’sieur j’ai pas tout compris !

Tout cela n’est pas forcément limpide du premier coup, il faut l’avouer.

En réalité la nouvelle syntaxe a peu de chance de se retrouver dans du code “de tous les jours”. En revanche cela permet à C# de supporter des concepts de programmation fonctionnelle propres à F# qui, comme par hasard, est aussi fourni de base avec .NET 4.0 et Visual Studio 2010. Covariance et contravariance seront utilisées dans certaines librairies et certainement dans le Framework lui-même pour que, justement, les délégués et les interfaces ainsi définis puissent être utilisés comme on s’y attend. La plupart des développeurs ne s’en rendront donc jamais compte certainement… En revanche ceux qui doivent écrire des librairies réutilisables auront tout intérêt à coder en pensant à cette possibilité pour simplifier l’utilisation de leur code.

Et les interfaces ?

Le principe est le même. Et comme je le disais la plupart des utilisations se feront dans des librairies de code, comme le Framework l’est lui-même. Ainsi, le Framework 4.0 définit déjà de nombreuses interfaces supportant covariance et contravariance. IEnumerable<T> permet la covariance de T, IComparer<T> supporte la contravariance de T, etc. Dans la plupart des cas vous n’aurez donc pas à vous souciez de tout cela.

Lien

La documentation est pour l’instant assez peu fournie, et pour cause, tout cela est en bêta ne l’oublions pas. Toutefois la sortie de VS2010 et de .NET 4.0 est prévue pour Mars 2010 et le travail de documentation a déjà commencé sur MSDN. Vous pouvez ainsi vous référer à la série d’articles sur MSDN : Covariance and Contravariance.

Conclusion

Les nouveautés de C# 4.0, qui peuvent toujours changer dans l’absolu puisque le produit est encore en bêta, ne sont pas à proprement parler des évolutions fortes du langage. On voit bien que les 3 premières versions ont épuisé le stock de grandes nouveautés hyper sexy comme les génériques ou Linq qui ont modifié en profondeur le langage et décuplé ses possibilités.

C# 4.0 s’annonce comme une version mature et stable, un palier est atteint. les nouveautés apparaissent ainsi plus techniques, plus “internes” et concernent moins le développeur dans son travail quotidien.

Une certaine convergence avec F# et le DLR pousse le langage dans une direction qui ouvre la polémique. Je suis le premier a resté dubitatif sur l’utilité d’une telle évolution surtout que la sortie de F# accompagnera celle de C# 4.0 et que les passionnés qui veulent à tout prix coder dans ce style pourront le faire à l’aide d’un langage dédié. Mélanger les genre ne me semble pas un avantage pour C#.

C# est aujourd’hui mature et il est peut-être temps d’arrêter d’y toucher…
L’ensemble .NET est d’ailleurs lui-même arrivé à un état de complétude qu’aucun framework propriétaire et cohérent n’avait certainement jamais atteint.
.NET a tout remis à plat et à repousser les limites sur tous les fronts.

On peut presque affirmer que .NET est aujourd’hui “complet”. Même si la plateforme va encore évoluer dans l’avenir. Mais tous les grands blocs sont présent, des communications à la séparation code / IHM, des workflows aux interfaces graphiques et multitouch, de LINQ au Compact Framework.

Quand un système arrive à un haut niveau de stabilité, le prochain est déjà là, sous notre nez mais on le sait pas. Le palier atteint par .NET 4.0 marque une étape importante. Cet ensemble a coûté cher, très cher à développer. Il s’installe pour plusieurs années c’est une évidence (et une chance !). Mais on peut jouer aux devinettes : quelle sera la prochaine grande plateforme qui remplacera .NET, quel langage remplacera C# au firmament des langages stars pour les développeurs dans 10 ans ?

Bien malin celui qui le devinera, mais il est clair que tout palier de ce type marque le sommet d’une technologie. De quelle taille est le plateau à ce sommet ? Personne ne peut le prédire, mais avec assurance on peut affirmer qu’après avoir grimpé un sommet, il faut le redescendre. Quelle sera la prochaine montagne à conquérir ? Il y aura-t-il un jour un .NET 10 ou 22 ou bien quelque chose d’autre, de Microsoft ou d’un autre éditeur, l’aura-t-il supplanté ?

C’est en tout cas une réalité qui comme l’observation des espaces infinis qu’on devine dans les clichés de Hubble laisse songeur…

Rêver bien, mais surtout et pour les dix ans à venir : Stay Tuned !

Quelques conseils de design (UserControl, Blend, Visual State manager, Silverlight / WPF)

odahan.nospam@nospam.e-naxos.com (Olivier) — Sun, 01 Nov 2009 07:36:00 +0200

L’une des avancées les plus intéressantes introduite dans Silverlight 2 (puis reprise sous WPF et naturellement sous Silverlight 3) est très certainement le Visual State Manager. Gestionnaire des états visuels simplifiant la conception visuelle des contrôles (UserControl). Bien utiliser le VSM, outre de rendre plus simple la représentation des états visuels d’un composant, apporte aussi une clarification essentielle à la gestion des transitions entre ces derniers.

Etats et transitions

Un contrôle peut être ou non visuel. Un Timer n’est pas visuel. Une Combobox l’est. Nous parlerons bien entendu ici uniquement des contrôles qui possèdent un visuel.

Un Etat visuel peut être compris comme une allégorie d’un ou plusieurs états logiques du contrôle. Les états logiques sont ceux définis dans le code fonctionnel, comme par exemple IsEnabled ou IsChecked. Il ne faut pas confondre état et propriété. Les états sont le plus souvent représentés par des propriétés (ils peuvent simplement être des champs internes ou le résultat d’un calcul) mais toute propriété ne représente pas un état (la couleur Foreground ou le type de curseur en sont des exemples).

je parle d’allégorie car comme je l’évoque dans le billet “Le défit des nouvelles interfaces Silverlight et WPF – La cassure conceptuelle”, la représentation visuelle d’un contrôle (et de ses états) est l’aboutissement d’une démarche intellectuelle et conceptuelle qui a justement pour but de créer un univers dans lequel les acteurs (les contrôles) doivent chacun avoir leur place et leur comportement. Entre visuel et fonctionnel il n’y a pas de relation d’identité (au sens d’un schéma conceptuel de données - relation de type 1-1). Le visuel créé une identité pour l’acteur, ce qui est différent et ne s’entend pas dans le même sens.

Je disais aussi qu’un état visuel représente un ou plusieurs états logiques. Dans certains cas deux (ou plus) états logiques peuvent être “résumés” par un seul état visuel. Cette combinaison prend son sens ponctuellement, au cas par cas, et ne peut pas être généralisée en une règle absolue. Néanmoins, lorsqu’on créé le visuel d’un contrôle, il faut garder à l’esprit cette possibilité. L’œil peut discerner de nombreuses subtilités dans les formes et les couleurs alors qu’il lui faut plus de temps pour interpréter des séries de données chiffrées ou textuelles…

Les transitions ont aussi leur importance. On ne passe pas d’un état visuel à un autre de façon abrupte, sauf si cela est volontairement assumé. Les transitions fluidifient l’interface, créent une continuité visuelle. Si les transitions ne portent pas de sens en elle-mêmes, à la différence des états, elles jouent un rôle important dans l’expérience utilisateur (UX).

Trois phases

La conception des états visuels et des transitions peut se découper en trois phases différentes.

Phase statique

Cette phase de la conception consiste à créer des états dans le VSM et à définir l’aspect du contrôle dans chacun d’eux. On en profite pour identifier les groupes d’états.

Au sein de chaque groupe les états sont mutuellement exclusifs, les états de différents groupes étant indépendants et simultanés (une Checkbox peut à la fois avoir le focus et être cochée ou décochée par exemple. IsChecked appartient à une groupe d’états différent de celui définissant l’aspect visuel pour le focus).

Lors de la phase de conception statique on se préoccupe de l’aspect que prend le contrôle dans chacun des états. On vérifie aussi la compatibilité visuelle entre les états des différents groupes d’états. Si cette étape est qualifiée de statique c’est pour souligner qu’on ne se soucie pas encore des transitions (la dynamique visuelle), mieux vaut rester concentré sur les groupes d’états et les états eux-mêmes.

On veillera à ne pas manipuler une même propriété du contrôle dans plusieurs groupes d’états pour des raisons de cohérence. D’ailleurs si on commet cette imprudence Blend le signalera par un petit symbole de danger (triangle assorti d’un message de type tooltip). On peut assumer une telle situation si on en mesure toutes les conséquences, c’est pourquoi Blend signale le problème mais n’interdit pas la situation. Mais en règle générale cette alerte trahit une mauvaise conception !

Etat “Base”

Vous l’avez peut-être remarqué, dès qu’un groupe d’états existe le VSM ajoute systématiquement à la liste un état spécial appelé Base. Cet état permet de visualiser le contrôle hors de tous les états visuels définis. Toute modification effectuée dans l’état Base se propage à tous les états définis et n’est enregistré dans aucune time-line.

Etat par défaut

Un contrôle bien conçu devrait posséder pour chaque groupe d’états un état par défaut. En effet l’état Base n’existe pas en tant qu’état visuel, il s’agit juste d’un mode d’édition spécial du VSM. Lorsqu’une instance du contrôle est créée il est forcément dans un état donné (par exemple IsChecked=False pour une case à cocher). Il se trouve même souvent dans plusieurs états précis qui seront représentés par plusieurs groupes d’états. De fait il ne faut pas se reposer sur l’état Base mais plutôt créer un état par défaut pour chaque groupe qui traduit l’aspect visuel du contrôle lorsqu’il vient d’être initialisé (ou “remis à zéro” si une telle fonction est disponible dans le contrôle). Dans les contrôles existants vous pouvez remarquer que de tels états par défaut existent. Par exemple dans le groupe CommonStates de la classe Button on trouve un état Normal, dans le groupe CheckedStates (d’une case à cocher) on trouve UnChecked, etc.

L’état par défaut de chaque groupe ne doit pas forcément porter un même nom (ce qui poserait un problème pour le VSM de toute façon, il n’autorise pas que deux états portent le même nom). Au contraire, cet état par défaut de chaque groupe doit, comme dans les exemples donnés ci-dessus, porter un nom ayant un sens en rapport avec le groupe.

Il est parfaitement valide de créer un état par défaut (ou non) qui ne fait que recopier la situation de l’état Base. Il suffit de créer l’état et de ne rien modifier… Cela permet souvent de clarifier les choses. Prenons l’exemple de la Checkbox, la croix est ajoutée dans l’état Base mais est cachée. En revanche cela ne lève pas l’obligation de créer un état Unchecked dans le groupe CheckedStates. Cet état est juste créé mais non modifié puisqu’il reprend l’aspect de l’état Base (croix cachée).

Validation des états

Arrivé ici il faut tester tous les états. Cela peut se faire sous Blend mais il ne faut pas hésiter à créer une fiche de test, y placer le contrôle, et ajouter des boutons, sliders, et autres éléments d’interface pour tester au runtime le changement de chaque état, la cohérence entre les groupes, etc.

Dans certains cas très simples la conception des états visuels peut s’arrêter là. On peut vouloir des transitions franches et immédiates et il n’y a alors plus rien à ajouter.

Dans d’autres cas il s’avère essentiel d’aborder la seconde phase.

Phase des transitions

La version simple consiste à utiliser le réglage par défaut que le VSM propose pour chaque groupe d’états. Dans de nombreux cas cela peut être suffisant. Il suffit alors de définir un temps pour l’ensemble des transitions. Le VSM calculera à l’exécution les animations correspondantes.

La version plus évoluée consiste à utiliser les options du VSM pour chaque état afin de régler les transitions d’entrées et de sorties de celui-ci. Il peut en effet s’avérer nécessaire d’avoir des timings différents selon le sens de la transition et l’état précédent. Par exemple il est courant que les états visuels de type clic souris soient instantanés pour ne pas donner l’impression à l’utilisateur que le logiciel est “mou”, lent à répondre, alors que le relâchement de la souris peut au contraire accepter un temps assez long, donnant une sensation de douceur, d’amorti “luxueux”.

Encore une fois les choses peuvent s’arrêter là. Bien entendu après avoir testé toutes les transitions. N’oubliez pas que Blend 3 propose désormais une option permettant de visualiser en conception l’effet des transitions lorsque le VSM est actif. Cela fonctionne très bien, sauf pour les transitions utilisant des storyboards.

Phase des transitions dynamiques

Justement le troisième niveaux de personnalisation consiste à créer des storyboards au lieu de se contenter des timings réglés dans le VSM. Dans ce cas on créé une animation complète pour la transition en utilisant les fonctions des storyboards (time line, boucle for-ever, autoreverse…).

Pouvant s’utiliser dans les storyboards ou sur les animations par défaut créées par le VSM, les fonctions de ease in et ease out permettent d’ajouter une touche “organique”, plus naturelle, aux animations. Silverlight 3 propose de nombreux modes (comme le rebondissement par exemple) qui, bien utilisés, finissent le visuel et le rende plus “pro”.

Relation avec le code

Il y a toujours eu deux aspects à la création d’un contrôle personnalisé, même sous Win32 avec les MFC ou sous Delphi avec la VCL. La création du visuel d’un côté et celle du code fonctionnel de l’autre. Tout a changé mais pas cette séparation qui s’est, au contraire, renforcée.

Le designer (l’infographiste) conçoit le visuel d’un contrôle, il prévoit comment le contrôle se comportera pour l’utilisateur, comment il s’animera, comment ses différents états seront visualisés.

Pour l’informaticien le point de vue est différent. Il ne doit pas se soucier de l’aspect visuel mais du comportement du contrôle, de sa logique sous-jacente.

Cela implique de prendre en compte tout ce qui peut modifier les états internes du contrôle, la cohérence de la machine logique lors de son fonctionnement. Que les changements d’état soient le fait de l’utilisateur, d’une animation créée par le designer ou de tout autre acteur, peu importe.

Il faut oublier le visuel qui d’ailleurs n’existe pas forcément (la séparation du travail design / codage est telle qu’on peut aujourd’hui commencer un projet par une réflexion purement conceptuelle et graphique avec un designer plutôt que d’écrire le cahier des charges avec un informaticien…).

Repérer les ilots d’états (qui deviendront ou non des groupes d’états dans la partie visuelle), le ou les graphes de changement d’état, vérifier quels sont les graphes d’états interconnectés (et qui forment un groupe ou des sous-groupes) de ceux qui sont totalement indépendants, tout cela est essentiel.

L’initialisation

On retrouve ici une préoccupation déjà évoquée quand nous parlions de la partie visuelle. Pour le designer il s’agissait de ne pas confondre l’état Base avec les états par défaut qu’il faut créer pour chaque groupe d’états.

Côté code il est indispensable que toute nouvelle instance d’un contrôle se “positionne” correctement. Normalement son initialisation comporte d’une façon ou d’une autre des valeurs par défaut. Sous C# il est possible d’atteindre cet objectif de multiples façons : soit par le biais de champs initialisés lors de leur déclaration, soit par le biais de valeurs par défaut mises en place dans les métadonnées des propriétés de dépendance, soit par code dans le constructeur de la classe, soit par code dans le gestionnaire de l’événement Loaded du contrôle (ou de l’une de ses sous-parties), soit encore par code XAML.

Le fait que ces différentes solutions puissent être utilisées simultanément dans un même contrôle n’aide pas forcément à rendre les choses claires… C#, comme tout langage, n’interdit pas le code spaghetti, hélas !

Mais ici en dehors de la pure stylistique, de l’académisme, voire même des bonnes pratiques, c’est aussi la stabilité visuelle qui risque d’être compromise si le contrôle ne s’initialise pas clairement dans une suite d’états bien déterminés (généralement les états par défaut).

Un contrôle a ainsi la charge lors de son initialisation de se positionner sur la case “départ” de son graphe d’états. Cela semble évident mais parfois les portes ouvertes sont celles qui méritent le plus d’être enfoncées. Tout le monde peut voir qu’une porte est fermée. Il faut être très perspicace pour s’apercevoir que l’absence d’un obstacle ne signifie pas qu’il n’y a rien à faire…

Car si rien n’est fait, le contrôle va être frappé d’une sorte de schizophrénie : il peut être doté d’un code qui s’initialise correctement et d’une interface qui en fait tout autant, hélas les deux personnalités existent simultanément et ne se connaissent pas forcément. Les cas de personnalités multiples sont passionnants en psychanalyse (je vous conseille d’ailleurs un excellent vieux livre écrit par une patiente atteinte de ce syndrome : Joan, autobiographie d’une personnalité multiple) et même s’il est plus facile de déboguer un programme qu’un cerveau humain, ce type de désordre du comportement ruine totalement les efforts pour créer une interface riche et cohérente… Alors autant y penser ! Cela signifie dans la pratique que vous devez centraliser l’initialisation logique de votre contrôle (l’ensemble de ses états) et l’initialisation visuelle. Cette dernière s’effectue en général en appelant GotoState avec le paramètre d’animation à false (il s’agit d’une bonne pratique. On évite d’animer les contrôles lorsqu’ils s’initialisent). Ainsi, code et visuel sont initialisés conjointement et sont en phase.

Encore une fois ne prenez pas Base pour un état. Notamment il n’existe aucune transition gérée par le VSM entre Base et les autres états. Si votre contrôle n’est pas volontairement initialisé dans ses états par défaut aucune animation ne sera jouée lors du premier changement car Base vers un état ne génère aucune transition.

Conclusion

La création d’un contrôle est une opération longue et minutieuse car elle doit être réfléchie. Et plutôt deux fois qu’une : à la fois sous l’angle visuel et sous l’angle du code. Ces deux aspects bien séparés aujourd’hui introduisent la nécessité de penser à leur indispensable synchronisation pour garantir la cohérence du contrôle.

Mais avec un peu d’habitude on s’aperçoit bien vite qu’il est mille fois plus facile de créer un nouveau contrôle visuel avec Blend (que cela soit pour Silverlight ou WPF) qu’avec les technologies précédentes. Alors cela vaut bien un peu d’attention au départ !

Bonne conception !

N’oubliez pas que seul Blend (qui hélas n’existe pas en version express gratuite) permet sérieusement de travailler sous Silverlight et WPF. N’hésitez pas à acheter ce complément indispensable ou à vous le faire offrir (après tout, un Blend 3 pour Noël c’est mieux qu’une cravate ou une bague – pas de sexisme sur Dot.Blog! – pensez-y ! )

Et Stay Tuned !

Mettez un peu de Live dans votre Windows !

odahan.nospam@nospam.e-naxos.com (Olivier) — Sun, 25 Oct 2009 23:07:00 +0200

Dans le précédent billet je grommelais un peu sur le système de recherche de fichiers de Windows. Microsoft ne fait pas que des bons choix, la perfection n’est pas de ce monde (ni d’un autre d’ailleurs à mon avis).

En revanche Microsoft a souvent de très bonnes idées, alors après les reproches, les louanges !

Comme vous le savez peut-être Microsoft met à disposition gratuitement un ensemble de services appelés Microsoft Windows Live .

Ces services se présentent sous la forme de logiciels à télécharger ou bien de services Internet. On y trouve Hotmail, la messagerie, Live Mail (remplace outlook express), Messenger, SkyDrive, Favorites, Spaces, Galery et Writer.

Bien entendu tout n’est pas nouveau (hotmail par exemple), et il s’agit pour l’essentiel d’un relookage commercial de MSN. Mais pas seulement.

Prenez par exemple Live Writer (téléchargeable à part), il permet de publier dans tous les blogs que vous possédez de façon centralisée tout en bénéficiant de la correction orthographique, de brouillons, etc. Writer sait même reconnaître le template de chaque blog et vous offre ainsi un espace de saisie ressemblant au look & feel de votre vrai blog dans sa version publiée.

Writer fonctionne très bien avec BlogEngine (le logiciel de blog Open Source en C#) et c’est d’ailleurs avec Writer que je publie maintenant mes billets, c’est bien plus pratique et plus complet que l’éditeur de BlogEngine. La plupart des services de blog sont reconnus automatiquement. On peut aussi visualiser un aperçu du billet en cours d’écriture dans une simulation du blog (mise en page en tout point conforme).

D’autres apprécieront la correction orthographique, d’autres flasheront sur la Galery de photo ou sur SkyDrive qui offre un espace de stockage et de partage de données sur le Web.

Je pense que chacun peut trouver son compte dans Windows Live sachant qu’on peut n’installer qu’un seul module sans être obligé de s’encombrer de toute la suite Live.

Au final, un ensemble de services bien pratiques, ni encombrants ni contraignants, et parmi lesquels il y en a forcément au moins un qui vous sera utile. Alors visitez le site Windows Live et installez les modules de vos choix !

Et Stay Tuned !

Everything, everywhere ! Accéder à tous vos fichiers de partout

odahan.nospam@nospam.e-naxos.com (Olivier) — Sun, 25 Oct 2009 21:01:00 +0200

Je ne sais pas pour vous, mais en ce qui me concerne j’ai l’impression que plus Microsoft fait des efforts pour améliorer la recherche des fichiers dans ses OS plus c’est compliqué et moins ça trouve…

Situation paradoxale s’il en est surtout que de quelques méga nos disques sont passés à des centaines de giga, donc à des centaines de milliers de fichiers. Sous XP c’était lent et pas toujours évident. Sous Vista ça ne trouvait déjà plus rien, même sur des supports indexés. Avec Seven on en reste là. Et pourtant Seven est un OS vraiment bien fait que j’utilise sur toutes mes machines aujourd’hui.

Mais vous me connaissez, j’aime bien rouspéter de temps en temps. Et malgré mes amitiés microsoftiennes c’est librement que parfois je m’exprime sur les produits de cet éditeur. J’en dit suffisamment de bien tous les jours pour pouvoir me le permettre ! :-) Et puis un ami qui ne dit pas la vérité, ce n’est pas un ami.

Syndrome Apple

Les améliorations ont été finalement trop “Applesques” c’est à dire “c’est nous qui nous occupons de tout, circulez y’a rien à voir ni à comprendre”. j’ai toujours détesté les Mac et leur OS pour ça. Il n’y a pas que des grand mères qui achètent des portables pour envoyer des mails à leurs petits enfants, il n’y a pas que des “utilisateurs de base” qui chattent sur MSN. Non, il y a aussi des professionnels, voire même des geeks, qui ont aussi besoin de chercher où se trouve un fichier “.wab” ce que Seven refuse de trouver (certainement parce qu’il se trouve dans un répertoire caché ou système).

Personnellement, étant de la génération qui a vu naître les premiers micros, et sachant comment ils sont fait je garde ce vieux réflexe dominateur : c’est moi l’homme, le PC n’est qu’une machine et c’est moi qui commande ! Pas de plan du genre l’horrible UAC de vista et ses incessantes demandes de confirmation. Si je fais un truc, je veux que le PC l’exécute sans me fatiguer avec des questions à la noix. J’ai besoin de me concentrer sur ce que je fais et pas sur le décryptage des messages de sécurité (qu’on finit par supprimer car trop de sécurité tue la sécurité. Ce que heureusement MS a compris dans Seven qui est bien plus discret, et donc utilisable).

Hélas, la recherche des fichiers si elle s’est améliorée pour le fameux utilisateur de base (chercher un document Word contenant le mot “anniversaire” ça c’est rapide) est devenue un enfer pour l’informaticien qui doit souvent localiser des fichiers qui se trouvent dans les endroits “interdits d’accès pour raison de sécurité”. Le vieil anar que je suis a tous les poils qui se hérissent rien qu’en écrivant cette phrase ! “interdit” “sécurité”, “raison d’état” pourquoi pas aussi !

Bref il fallait que je trouve un système de recherche efficace qui puisse me redonner le pouvoir que j’exige sur mes machines, surtout que ma machine principale, outre ses deux disques de 500 Go, est connecté à divers disques externes de 1 To. Autant dire que si je compte sur Windows pour m’aider à trouver quelque chose là dedans, je n’ai plus qu’à me tirer une balle…

Everything

A force de chercher on trouve ! (sauf le système de recherche de Windows).

Et j’ai fini par trouver un utilitaire puissant, simple, léger et gratuit qui fait exactement ce que je veux. Il s’appelle “Everything Search Engine”.

Son principe est simple : il utilise les structures NTFS qu’il balaye pour constituer sa base de recherche. C’est mille fois plus rapide que le balayage des répertoires via Windows et les temps de recherche sont de l’ordre de quelques millisecondes. La création de la base de données (quelques méga qui se met à jour toute seule ensuite) a pris une minute ou deux avec tous mes disques branchés. Ensuite tout est quasi instantané.

Bien entendu Everything ne cherche pas le contenu des fichiers. Windows autorise des noms longs depuis quelques lustres, tant pis pour ceux qui donnent encore des noms courts et ne voulant rien dire à leurs fichiers !

Everything sait utiliser les expressions régulières ou bien une notation très simple permettant de faire des AND et des exclusions (mode de recherche simplifié). La liste des fichiers est triée, ce qu’on peut changer à volonté, et les fichiers sont cliquables pour des actions de base (exécuter, supprimer, etc).

Mais il y a mieux ! Everything peut aussi fournir ce service “Everywhere” !

Everywhere

Ce petit utilitaire est en effet assez puissant pour incorporer un serveur Web (dont le port est paramétrable, ainsi que la sécurité d’accès par mot de passe) !

Il devient ainsi possible depuis n’importe quelle machine sur le réseau de faire une recherche sur les fichiers de la machine équipée de Everything depuis un browser internet :

L’image ci-dessus montre l’écran d’une machine accédant au serveur Everything de la machine Saturne (sur le port 100, réglage personnel, le port 80 étant occupé par IIS). Il suffit de saisir la phrase de recherche et de cliquer sur le bouton Search pour obtenir un listing détaillé depuis lequel il est possible de télécharger le fichier par exemple. Très pratique.

Conclusion

Pouvoir chercher en quelques millisecondes sur des Tera de stockage n’est une pas une fantaisie de geek bien entendu, c’est une fonction de base que tout OS devrait être capable de fournir. La tendance Apple où l’utilisateur ne doit rien savoir et rien pouvoir faire, ou bien l’excès de vouloir trop bien faire, ou tout simplement une mauvaise analyse du besoin, un peu de tout ça peut-être… En tout cas la recherche de fichiers sous XP, Vista et aujourd’hui Seven est une vraie plaie. Il a fallu attendre Internet Explorer 8 pour que le mode de recherche dans une page soit enfin pratique (du même genre que celui de FireFox), j’espère qu’il ne faudra pas attendre encore trois ou quatre versions de Windows avant qu’un mode de recherche simple et rapide soit enfin intégré à l’OS ! Surtout si Seven fait une carrière comme XP (ce que je lui souhaite), dans 4 versions ce seront mes petits enfants que je formerai au nouvel outil !

Comme entre temps il faut bien se débrouiller, je vous conseille de télécharger et d’utiliser Everything !

Bonne recherche… Et Stay Tuned !

Lequel est le plus foncé sous WPF/Silverlight : Gray ou DarkGray ?

odahan.nospam@nospam.e-naxos.com (Olivier) — Thu, 15 Oct 2009 05:12:00 +0200

La réponse n'est pas forcément celle que vous pensez !

La taille du cul des vaches

Rappelez-vous, il y a de de cela plusieurs années circulait sur Internet une histoire (vraie ou fausse peu importe) qui démontrait que le diamètre des fusées de la Nasa dépendait, par une suite invraisemblable de relations de cause à effet, de la taille du cul des vaches au temps des romains. On passait par la taille des charriots dont la largeur dépendait justement de celle du fessier des ces honorables bovins, ce qui imposait une distance entre les roues, elles-même créant des traces au sol qui firent que les premières voitures à cheval, pour emprunter les routes aux ornières profondes tracées par les charrues se devaient de respecter la même distance inter-roue, etc. On en arrivait ainsi au diamètre des fusées qui, pour passer sur les trains, qui devaient passer dans les tunels, dont la taille dépendait etc, etc... Au final un objet ultra technologique et on ne plus moderne se retrouvait à respecter une taille qui dérivait de celle du cul des vaches des romains...

Je n'ai pas pu retrouver cette histoire le Web pour vous mettre la référence, si un lecteur la connaît qu'il soit sympa et qu'il laisse le lien en commentaire...

Une histoire plus vraie qu'on le pense

Bien entendu je n'ai jamais pu savoir à l'époque s'il s'agissait d'un hoax, d'une véritée romancée ou bien d'une vérité historique. Mais l'histoire que je vais vous raconter aujourd'hui me fait penser, des années plus tard, que cette histoire était probablement vraie...

Je tire librement inspiration d'un billet publié en 2006 par Tim Sneath, ceux qui désirent lire ce billet original (en anglais) n'ont qu'à cliquer ici.

Les couleurs sous WPF / Silverlight

24 bit RGB

En Xaml il existe plusieurs façons d'exprimer une couleur. Une des options est d'utiliser la notation 24 bits hexadécimale de type RGB (Red/Green/Blue, rouge/vert/bleu) :

<Rectangle Fill="#B2AAFF" Stroke="#10F2DA" ... />

32 bit ARGB

Comme WPF et Silverlight savent gérer la transparence via le canal dit Alpha, on peut spécifier une couleur par un code hexadécimal 32 bits dit A-RGB (Alpha / RGB) :

<Line Stroke="#7F006666" ... />

Ce qui donnera une ligne en Cyan à 50% d'opacité.

scRGB

Plus subtile et bien moins connu (et encore moins utilisée) est la notation scRGB qui permet d'exprimer une couleur sous la forme de 4 nombres décimaux de type Single ce qui autorise la représentation d'un gamut ultra large. A quoi cela peut-il servir d'utiliser un système de notation des couleurs qui dépasse de loin les limites du RGB qui va de #000000 à #FFFFFF ? Créer un noir plus noir que le noir ou un blanc plus blanc que blanc, à part si on est on un publiciste en mal d'argument pour une nouvelle lessive, cela semble idiot.

Et pourtant cela ne l'est pas. Il n'y a qu'en matière de lessive que "plus blanc que blanc" est une ânerie (dont Coluche se délecta dans un sketch célèbre). Lorsqu'on parle infographie cela peut avoir un sens très concret : conserver les couleurs originales si celles-ci doivent subir de nombreux traitements, comme par exemple une correction du contraste ou de la Hue (teinte dans le système HSL). En effet, à force de calcul, d'arrondis et d'approximations, votre filtre de correction peut finir par créer des à-plat horribles. En utilisant le système scRGB, le code (qu'il soit C# ou XAML) pourra conserver le maximum d'information sur chaque composante couleur.

Un exemple de notation scRGB :

(cela donne un rectangle jaune à bords arrondis bistres).

Les couleurs nommées

Enfin, il est possible d'utiliser des noms pour définir des couleurs.

WPF et Silverlight divergent sur ce point car, économie de code oblige pour le Framework réduit de Silverlight, ce dernier ne contient pas toutes les définitions de couleur de son aîné WPF. Mais le principe reste rigoureusement le même (je vous joint d'ailleurs en fin d'article un code qui définit toutes les couleurs WPF utilisables sous Silverlight).

On peut ainsi utiliser des noms tels que : Green, SteelBlue ou MediumVioletRed. Ce qui donne en XAML :

<Rectangle Stroke="yellow" Fill="red" Width ="50" Height="50" />

Et le cul des vaches ?

C'est là que l'affaire devient croustillante... Attendez la suite pour juger !

Par souci de compatibilité avec HTML et SVG, Microsoft a repris la liste des couleurs définies dans ces standards. Une bonne idée, on a souvent accusé Microsoft de ne pas respecter les standards, ce que j'ai toujours trouvé idiot puisque justement l'innovation vient de ce qui est différent et non de l'uniformisation. Et bien justement, quand les développeurs de chez Microsoft se plient à cette servile obligation, cela donne des choses bien curieuses (à l'insu de leur plein gré comme disait l'idiot pédaleur).

En effet, la liste des couleurs HTML est pleine de bizarreries et d'idiosyncrasies qu'il eut été préférable de corriger. Expurgée de ces annomalies la liste des couleurs HTML aurait pu faire une belle liste pour XAML, mais voilà, compatibilité oblige (en fait rien ne l'obligeait, sauf les habitudes), on se retrouve dans l'un des environnements de développement le plus moderne à trainer des bêtises d'un autre âge ! La fameuse taille du cul des vaches au temps des romains influençant le diamètre des fusées de la Nasa...

Par exemple, le spectre couvert par les couleurs HTML ne respecte pas même une répartition à peu près homogène, ce qui fait qu'on dispose de très nombreuses teintes dans les rouges ou les oranges alors que les verts sont très mal couverts.

Autre exemple, les couleurs ont parfois des noms ésotériques qui montrent à quel point les auteurs originaux n'avaient aucune volonté de rendre l'ensemble compréhensible. En dehors d'un américain pure souche, qui peut bien en Italie, en France ou en Slovénie s'imaginer de quel bleu il s'agit lorsque HTML nous indique un "DodgerBlue" ? La charte couleur des Tshirts d'une équipe d'un sport totalement inconnu (le baseball) chez nous n'évoque rien (les dodgers sont en effet une équipe de baseball de Los Angeles, très connus certes, mais uniquement des américains et des rares amateurs étrangers).

Des origines encore plus lointaines

Mais si cela s'arrêtait là le rapprochement avec la petite histoire sur l'arrière train des vaches pourrait sembler un peu capilotractée. En fait nous sommes exactement dans le même cas. Car les choses ne s'arrêtent pas à HTML. Ces couleurs remontent en réalité aux premières implémentations sous UNIX du système X-Window ! HTML définit 16 couleurs qui sont directement mappées sur les 16 couleurs de la palette EGA. Mais plus loin encore, les premiers browsers comme Mosaic (1992) supportaient aussi les couleurs nommées de X11 ! Malheureusement certaines couleurs HTML avaient des homonymes X11 qui, bien entendu, ne donnait pas exactement la même teinte... par exemple ce vert HTML donnait ce vert sous X11.

Un gris plus foncé que le gris foncé

Et c'est ainsi que de tout ce mélange le Gray HTML fut défini par #808080 alors que le DarkGray est défini par #A9A9A9, un gris plus clair que le gris...

On en revient à la question posée dans le titre de ce billet. Et vous voyez que la réponse est loin d'être celle qui semble s'imposer en toute logique !

WPF et Silverlight réutilisent cette liste de couleurs qui ne remonte pas aux temps des romains, mais pour l'informatique, l'époque de X11 c'est même pire : de la préhistoire !

Du coup, il semble bien plus intelligent d'utiliser les codes couleurs RGB, ARGB ou scRGB que les couleurs nommées si on ne veut pas obtenir des résultats étranges...

Incroyable non ?

On pourrait tirer milles conclusions de cette petite histoire. Je vous laisse y réfléchir, je préfère ouvrir des portes que d'asséner des jugements définitifs. Poser des questions ou créer le questionnement est souvent bien plus utile que d'apporter des réponses toutes faites.

On peut aussi juste en rire, c'est bon pour la santé :-)

Stay Tuned !

(pour ceux qui ont lu jusque là, le cadeau annoncé : ColorHelper.cs (16,31 kb) )

Silverlight : Enum.GetValues qui n'existe pas, binding et autres considérations

odahan.nospam@nospam.e-naxos.com (Olivier) — Fri, 09 Oct 2009 00:23:00 +0200

Silverlight, comme vous le savez, propose dans quelques méga octets un mini framework .NET qui est tellement bien "découpé" que la plupart du temps on ne se rend même pas compte qu'il manque des dizaines de méga de code binaire... Pourtant entre une installation complète du Framework 3.5 ou 4.0 à venir et l'installation du plugin Silverlight il y a comme une énorme différence ! De deux choses l'une, soit Silverlight ne sait rien faire tellement il est diminué par ce découpage, ce qui n'est pas le cas, soit le Framework complet est juste gonflé avec des fichiers inutiles pour "faire sérieux", ce qui n'est pas le cas non plus :-)

Un découpage savant

Donc ce n'est ni l'un ni l'autre. La troisième possibilité, qui est la bonne réponse, est que le Framework complet est d'une richesse infinie dans les moindres détails, et que le Framework Silverlight "ruse" en zappant beaucoup de détails mais sans perdre l'essentiel. Cela donne l'impression qu'on peut tout faire en Silverlight comme en WPF. C'est "presque" vrai. Assez rapidement on tombe sur les fameux petits détails qui manquent. Cela implique de les compenser par du code.

Cela dit loin d'être une critique négative de Silverlight s'en est au contraire une apologie ! Je trouve en effet le découpage savant qui a été effectué dans Silverlight particulièrement bien fait. L'approche est très sensée : il est rarissime (même impossible) qu'une application utilise et nécessite d'accéder à toutes les méthodes, toutes les propriétés de toutes les classes du Framework tellement celui-ci est riche. Du coup, en faisant des coupes bien choisies, on peut laisser les squelettes de presque tout le Framework ainsi que les principales méthodes et propriétés utilisées le plus souvent. On obtient le Framework Silverlight dans lequel un code standard trouvera 95% de tout ce qu'il lui faut pour tourner. Beaucoup d'applications simples ne verront même pas qu'il manque quelque chose. En revanche pour les autres cas, le développeur ajoutera les contournements nécessaires ce qui grossira un peu son code binaire Silverlight, mais d'une petite fraction très supportable. Rien à voir avec le coût d'une installation du Framework complet.

Il n'en reste pas moins vrai que parfois pour des choses très simples on se retrouve un peu le bec dans l'eau. "Tiens, c'est bizarre, j'aurais juré que la méthode xxx existait !" Et non, on n'a pas rêvé, elle existe bien, mais dans le Framework complet, pas dans celui de Silverlight. Un exemple tout simple : la méthode GetValues() de la classe Enum.

Enum.GetValues où es tu ?

Un cas d'utilisation très basique qui fait voir immédiatement qu'il manque quelque chose : essayez de faire un binding entre une combobox et une énumération. Truc classique par excellence.

Que le binding soit fait par Xaml ou bien par code, à un moment où un autre il faut que l'énumération sache retourner la liste de ses valeurs. C'est justement la fonction de la méthode Enum.GetValues().

Mais dans le Framework Silverlight cette méthode n'existe tout simplement pas. Victime de la cure d'amaigrissement évoquée plus haut. Il ne s'agit donc ni d'un oubli ni d'un dommage collatéral, c'est un parti pris, assumé.

Et alors on fait comment ?

Assumé, assumé... comme il y va ! Non, je vous l'assure, c'est assumé. Par l'équipe qui développe le Framework Silverlight en tout cas. Mais pas forcément par les développeurs qui l'utilisent ! Car pour eux c'est une autre histoire puisque, en effet, il va falloir réinventer cette méthode.

A l'aide d'un peu de Linq to Object et de Reflexion, on peut s'en sortir.

Linq et Reflexion

Il existe en effet un moyen d'obtenir les valeurs d'une Enum par la réflexion, en utilisant la méthode GetFields() sur le type de l'Enum dont on souhaite obtenir les valeurs.

GetFields() retourne un tableau de FieldInfo. Une Enum présente alors ses différentes valeurs comme un tableau de champs. En plus de ces champs, GetFields() retournera aussi des éléments qui ne sont pas des valeurs de l'énumération mais d'autres champs de la classe. Au sein de FieldInfo vous trouverez un ensemble de méthodes nommées Isxxx(), l'une d'entre elles nous intéresse plus particulièrement ici; c'est IsLiteral. Toutes les valeurs de l'énumération retournent True. La solution est alors simple en ajoutant à la Réflexion un peu de Linq to Object :

   1:  var enumType = typeof(monEnumeration);

   2:  var fields =  from field in enumType.GetFields()

   3:                where field.IsLiteral

   4:                select field.GetValue(null).ToString();

   5:  LaCombobox.ItemsSource = fields;

A partir du type de l'énumération (ligne 1) on construit une requête Linq to Object qui filtre tous les champs ayant IsLiteral à vrai et qui sélectionne la valeur de ce champ sous la forme d'une string.

Ne reste plus qu'à faire le binding entre cette requête Linq et ItemsSource de la combo box.

Il faudra ajouter un peu de code pour transformer la chaîne sélectionnée dans la combo en une valeur de l'énumération grâce à un appel à Enum.Parse().

C'est la version simple et courte. Bien entendu dans le cas où on souhaite faire du binding plus automatisé, notamment directement en Xaml, la solution donnée ici est un peu trop simple. L'esprit est le bon mais il manque des petites choses comme un convertisseur de valeurs.

D'autres versions plus sophistiquées

Il est bien sûr possible d'aller plus loin et de formuler une solution plus sophistiquée qui permettent de faire du binding en Xaml notamment. Je vous laisse y réfléchir, ça fait un bon excercice C# et ce n'est pas un MVP C# qui vous dira que s'entraîner mentalement de la sorte sur le langage est inutile ! :-)

Mais sachez que d'autres y ont déjà pensé et ont proposé des solutions souvent assez proches (ce problème ne peut pas être résolu de dix milles façons). En voici quelques unes dans lesquelles vous pourrez piocher matière à aller plus loin :

Blog'A'Little (missing GetValues)
Forum Silverlight (binding button group)
Forum Silverlight (databinding to an enumeration)
Brant's Web blog (binding combobox)
Telerik forums (enumeration binding)
et d'autres que vous trouverez certainement vous-mêmes !

Silverlight c'est sympa et en plus ça fait travailler les méninges, que du bon !

Stay Tuned !

Fichiers PFX de signature de projet Visual Studio / objet déjà existant après migration Windows 7

odahan.nospam@nospam.e-naxos.com (Olivier) — Thu, 08 Oct 2009 01:16:00 +0200

Vous l'avez compris, l'entrée de blog d'aujourd'hui ne parle pas de Silverlight ni d'autres sujets technologiques passionnants mais d'un problème très ennuyeux intervenant après la migration sous Windows 7. Cela concerne les projets signés numériquement sous Visual Studio, ceux possédant un fichier PFX donc.

Une fois cette migration effectuée, tout semble tellement bien marcher que vous lancer fièrement Visual Studio sans vous douter du complot sournois qui se trame contre vous et qui se révèlera au moment où vous tenterez d'ouvrir une solution contenant des projets signés... Vous allez me dire, l'attente est courte. En effet, il est rare d'ouvrir VS juste pour le plaisir de le regarder, assez rapidement, même pour les plus lents d'entre nous, on finit par faire Fichier / Ouvrir (les plus créatifs préférant Fichier / Nouveau, mais ce n'est pas le sujet du jour).

A ce moment là, tous les projets signés déclenchent une importation du fichier PFX (même si vous êtes toujours sur la même machine et que rien n'a changé, n'oubliez pas que cette machine vient de migrer de Vista à 7 !). Comme vous êtes un développeur honnête, vous connaissez bien entendu les mots de passe des fichiers PFX de vos projets. Donc pas de problème vous tapez le mot de passe. Bang ! Erreur "l'objet existe déjà" (Object already exists). Et pour peu que votre solution contienne des dizaines de projets, ce qui est mon cas assez fréquemment, vous allez boucler sur cette séquence pour tous les fichiers PFX. A la fin vous pourrez travailler sur votre solution, mais à toute tentative de compilation vous vous reprendrez la même séquence : importation de la clé, demande de mot de passe, échec pour cause d'objet existant, etc pour chaque projet signé.

C'est un peu gênant... Mais il existe une raison et une solution !

La raison, en tout cas pour ce que j'en ai vu, c'est que la migration vers W7 modifie les droits du répertoire dans lequel sont cachés les clés importées. Pourquoi ? Je n'en sais rien et pour l'instant je n'ai rien trouvé sur le Web à ce sujet.

En tout cas, le problème étant identifié, il existe une solution : changer les droits et s'approprier le dit répertoire. Ca peut être plus compliqué que prévu, en tout cas j'ai galéré un peu (j'avoue franchement ne pas avoir un niveau d'expert en matière de gestion de sécurité sous Windows). En effet il faut déjà trouver le répertoire en question. (roulements de tambours) c'est... c'est... C:\Users\All Users\Microsoft\Crypto\RSA

Maintenant que faire... Clic droit sur le répertoire (dont l'image possède un petit verrou d'ailleurs, verrou qui disparaitra en fin de manip), onglet sécurité et on essaye de s'approprier tout ça. Ca plantouille car Windows répond qu'on n'a pas les droits sur xxxx (à remplacer par le nom imbuvable de chaque fichier de ce répertoire, justement ceux posant problème).

Bref, il faut y aller à la main. On entre dans le répetoire et on fait un clic droit / sécurité sur chaque fichier. Certains laissent voir la page Sécurité immédiatement. Laissez tomber. Mais un certain nombre d'autres fichiers affichent un message vous indiquant que vous n'avez pas le droit de voir l'onglet Sécurité ! Heureusement Windows vous permet de vous les approprier, donc d'en devenir le propriétaire (au passage je vois mal l'intérêt d'interdire un truc en proposant de l'autoriser, je vous l'ai dit, je ne suis pas un expert en Sécurité Windows !). C'est ce que j'ai fait pour chaque fichier. En fin de manip j'ai recommencé la modification des droits sur le répertoire lui-même, et là c'est passé. Plus de petit verrou affiché dans le symbole dossier.

Et immédiatement, Visual Studio ne redemande plus l'importation des clés. Ca remarche. Ouf !

Je suis convaincu que je m'y suis pris comme un pied pour régler le problème (il doit y avoir plus simple et plus propre que de devenir propriétaire de chaque fichier un par un), en tout cas ça règle bien le problème qui avait été bien identifié : problème de droits sur le répertoire des clés.

Pour l'instant c'est la seule surprise que j'ai eu en migrant cette machine de Vista à Windows 7. Le reste marche très bien et on ne perd rien ce qui est très appréciable (comme j'aurai aimé que cette option de migration sans douleur existe sur les anciennes versions de Windows !).

J'espère que le récit de cette mésaventure (et surtout sa solution) évitera à certains de perdre quelques heures... Si oui, n'hésitez pas à me le dire, ça fait toujours plaisir de savoir qu'un billet a été utile !

Et sir parmi vous il y en a qui sont plus doués que moi niveau sécurité Windows, qu'ils n'hésitent pas à indiquer la "bonne" manip pour arriver au résultat je modifierai en conséquence le présent billet...

Dans tous les cas, Stay Tuned !

Silverlight : Contrôle et zone cliquable, astuce...

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 07 Oct 2009 04:27:00 +0200

Une petite astuce toute simple pour aujourd'hui (une fois que l'on connaît la réponse).

Un contrôle très basique pour commencer

Prenons un contrôle, un UserControl carré avec un joli cercle à l'intérieur. Pour que tout cela soit facile à comprendre et à tester, disons que le UserControl fait 200x200 pixels, et que l'ellipse à l'intérieur remplie toute la zone (c'est un cercle donc). Cette ellipse aura un Stroke noir par exemple et une épaisseur de trait de 12. Le LayoutRoot sera un Canvas.

Donc, nous avons : un UserControl de 200x200 contenant un Canvas (toutes les propriétés par défaut), ce Canvas contient une ellipse qui remplit la zone du contrôle, l'ellipse possède un Stroke de 12 en noir. En gros nous avons dessiné un cercle noir sur fond transparent.

"Hou la la ! Mais c'est du super haut niveau tout ça !" ... On ne s'inquiète pas, ça va très vite se compliquer ...

Première petite amélioration : nous allons mettre un curseur personnalisé à notre contrôle. Dans les propriétés du UserControl, propriété Cursor, on choisit Hand, (la main). Et on exécute (F5).

Ca se complique...

Passer la souris au-dessus de votre magnifique contrôle : la main s'affiche bien, mais uniquement lorsque votre souris survole le Stroke du cercle ! Rien à l'intérieur.

Qu'est ce qu'il se passe ?

Pour ce que j'en comprends, tout ce qui n'a pas une brosse n'existe pas. Notre contrôle et le Canvas sous-jacent n'ont pour l'instant aucune couleur de fond (Background). L'ellipse n'a pas de Fill non plus. Tous ces espaces "sans rien" ne sont visiblement pas détectés. Bug ou feature, après tout ça peut être l'un ou l'autre selon le point de vue...

Mais comment régler le problème ?

En fait qu'importe qu'il s'agisse d'un problème ou d'un choix délibéré des concepteurs, nous devons remplir ces "riens" si nous voulons que le curseur de souris (et la zone cliquable du contrôle) apparaisse sur toute la surface.

Mais il est hors de question d'aller placer une brosse, donc une couleur, pour faire ce travail ! On pourrait bien entendu mettre un Background blanc au Canvas, cela règlerait le problème. Mais si nous changeons le fond de notre page, nous allons obtenir un cercle dans un carré blanc sur un fond différent. Une horreur. Quant à s'enliser dans l'erreur pour faire en sorte de trouver une astuce pour que le fond de notre UserControl soit synchro avec celui de son conteneur parent...

Une "fausse" brosse

Il faut remplir notre ellipse pour que le curseur soit visible et que même son espace intérieur soit cliquable. Mais pas avec n'importe quoi. Xaml nous fournit une brosse un peu spéciale, disons une "non brosse", ou une "fausse" brosse puisque visuellement elle ne se voit pas. Il s'agit de la brosse "Transparent".

Dès lors, il suffit d'ajouter dans le code Xaml de notre ellipse Fill="Transparent" et de relancer l'application. Miracle ! Le curseur en forme de main est visible même à l'intérieur de l'ellipse. Et si nous changeons la couleur de fond de la page, comme cette brosse est transparente, on n'y verra que du feu ...

Sous Blend vous pouvez agir directement dans le code Xaml ou bien simplement cliquer sur le carré de binding de la propriété Fill et choisir "custom expression". Tapez "Transparent" (sans les guillemets) dans le champ de saisie et l'affaire est jouée.

Comme quoi, même un UserControl ne contenant qu'un cercle peut déjà soulever des problèmes pas si simples à résoudre. Ca force à l'humilité... :-)

Stay Tuned !

Security Essentials enfin disponible ! (un anti virus gratuit)

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 30 Sep 2009 00:27:00 +0200

Il y a un bon moment déjà (nov 2008) je vous parlais dans le billet "Morro .. Vache ? (ou les nuits blanches d'Avast, McAfee et Symantec)" du projet de Microsoft de rendre sa solution de sécurité One Care gratuite, notamment la partie anti-virus. En juin 2009 je vous annonçais (dans le billet "Microsoft Security Essentials en bêta") que la solution Security Essentials était passée en phase béta, mais uniquement aux USA.

Désormais vous aussi vous pouvez utiliser Security Essentials gratuitement ! Simplement en vous rendant sur le site de Security Essentials et en téléchargeant le logiciel. Il existe des versions localisées (en Français entre autres) et l'installation s'effectue en un clin d'oeil. Après le téléchargement des mises à jour et un balayage rapide de vos disques, SE va s'occuper de tous les virus, malwares et autres spywares qui veulent saboter votre PC.

Comparativement à la meilleure solution gratuite alternative utilisée jusqu'à maintenant, Avast, Security Essentials est moins gourmand, plus efficace, mais en revanche s'occupe de moins de choses. Par exemple Avast utilise 7 processus différents pour le mail, les sites web filtrés (anti pub), etc. Lorsqu'on utilise S.E. on ne dispose plus de ces petits avantages qu'on retrouvent soit avec des logiciels gratuits supplémentaires, soit en configurant correctement son PC et son browser !

Personnellement j'ai opté pour cette dernière approche suivant le principe que toute solution de sécurité fiable se doit d'être simple avant d'être sophistiquée... Ainsi, en paramétrant correctement IE8 et le pare-feu de Windows, sans parler bien entendu du paramétrage de la box internet, on arrive à une sécurité certainement aussi totale qu'avec 50 logiciels ultra sophistiqués...

Dans tous les cas, avec Security Essentials, Microsoft s'invite dans le petit monde des anti virus gratuits. Nul doute que la surenchère que cela va imposer à ses concurrents va mettre un coup de pied dans la foumilière un peu trop tranquille qu'était devenu ce marché des anti-virus !

Sortez couvert !

(et Stay Tuned, cela va sans dire :-) )

44 Videos US et 11 Ateliers en français sur Silverlight !

odahan.nospam@nospam.e-naxos.com (Olivier) — Fri, 25 Sep 2009 22:41:00 +0200

Dans un billet de 2008 je vous parlais de l'extraordinaire travail publié par Mike Taulty, 44 vidéo autour de Silverlight (V 2 à l'époque) ! Cette série reste toujours d'actualité pour se former, mais elle peut gêner ceux qui ne pratiquent pas assez bien l'anglais pour capter chaque leçon. Si j'en reparle c'est que les liens que j'avais donnés à l'époque ne sont plus bons et qu'il était nécessaire de les réactualiser (grâce à la vigilance d'un lecteur que je remercie au passage !). C'est chose faite dans le présent billet.

Mais j'en profite aussi pour vous parler d'une superbe série d'ateliers que Microsoft vient de mettre en ligne. Le coach Silverlight (David Rousset bien connu pour son blog notamment) a beaucoup travaillé cet été pendant que vous profitiez de la plage ! Il était prévu à l'origine que les 12 ateliers soient mis en ligne progressivement (David veut écrire un petit topo avec chaque module et ça réclame un peu de temps). Mais devant le succès des premiers modules et l'insistance des lecteurs, Microsoft a décidé de mettre tous les ateliers en ligne, David complètera les modules de leur petit topo au fur et à mesure.

Si on compte bien, 44 + 11 ça donne 55 modules de formation gratuits pour prendre en main Silverlight... Les longues soirées d'automne vont être chargées et vous pouvez d'ores et déjà prévoir de laisser votre Wii à vos enfants, vous n'allez pas beaucoup y toucher dans les semaines à venir !

L'accès direct aux sommaire des 44 casts US : http://misfitgeek.com/blog/44-silverlight-videos/

Le sommaire pour se mettre l'eau à la bouche :

Silverlight - Hello World
Silverlight - Anatomy of an Application
Silverlight - The VS Environment
Silverlight - Content Controls
Silverlight - Built-In Controls
Silverlight - Width, Height, Margins, Padding, Alignment
Silverlight - Using a GridSplitter
Silverlight - Grid Layout
Silverlight - StackPanel Layout
Silverlight - Canvas Layout
Silverlight - Databinding UI to .NET Classes
Silverlight - Simple Styles
Silverlight - Custom Types in XAML
Silverlight - Binding with Conversion
Silverlight - List Based Data Binding
Silverlight - Simple User Control
Silverlight - Templating a Button
Silverlight - Resources from XAP/DLL/Site Of Origin
Silverlight - Animations & Storyboards
Silverlight - Uploads with WebClient
Silverlight - Downloads with WebClient
Silverlight - Calling HTTPS Web Services
Silverlight - Calling Web Services
Silverlight - Making Cross Domain Requests
Silverlight - Using HttpWebRequest
Silverlight - File Dialogs and User Files
Silverlight - Using Sockets
Silverlight - Using Isolated Storage
Silverlight - .NET Code Modifying HTML
Silverlight - Using Isolated Storage Quotas
Silverlight - Calling JavaScript from .NET
Silverlight - Evaluating JavaScript from .NET Code
Silverlight - Handling HTML Events in .NET Code
Silverlight - Handling .NET Events in JavaScript
Silverlight - Calling .NET from JavaScript
Silverlight - Displaying a Custom Splash Screen
Silverlight - Passing Parameters from your Web Page
Silverlight - Loading Media at Runtime
Silverlight - Dynamically Loading Assemblies/Code
Silverlight - Reading/Writing XML
Silverlight - Multiple Threads with BackgroundWorker
Silverlight - Insert/Update/Delete with the DataGrid
Silverlight - Getting Started with the DataGrid
Silverlight - Embedding Custom Fonts

Le coach français : http://msdn.microsoft.com/fr-fr/silverlight/msdn.coachsilverlight.aspx

Et le sommaire pour vous donner encore plus envie d'y aller tout de suite :

Stay Tuned pour d'autres infos !

Blend survey : donnez votre avis pour le prochain Blend 4 !

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 16 Sep 2009 05:16:00 +0200

Microsoft prépare déjà la prochaine version de Blend qui, avec la version 3, est déjà un outil d'une grande maturité. Mais on peut toujours faire mieux... Alors au lieu de grogner dans votre coin, dites ce que vous aimez ou pas, proposez ce qui vous semble manquer, bref répondez au sondage lancé par l'équipe Blend : https://connect.microsoft.com/Expression/Survey/Survey.aspx?SurveyID=9391

Attention, ce sondage est assez long (pas énorme mais bien plus que trois cases à cocher) prévoyez un petit quart d'heure, et, of course, totalement en anglais avec pas mal de zones de commentaires qu'il faudra remplir dans la même langue. N'oubliez pas que google traduction est votre ami et qu'il vaut mieux donner votre avis que de vous taire, même si certains commentaires sont traduits par une machine (demandez à un collègue plus anglophone que vous de relire quand même :-) ).

A la clé, un Zune à gagner par tirage au sort. Mais surtout, un Blend 4 plus proche de vos besoins.

Alors exprimez-vous !

Création de jeux et détection de touches clavier multiples sous Silverlight

odahan.nospam@nospam.e-naxos.com (Olivier) — Thu, 10 Sep 2009 22:39:00 +0200

Silverlight est conçu pour s'intégrer dans une chaîne de développement "sérieuse". Son but est principalement la création de RIA (Rich Internet Application) le plus souvent associées à des applications métier. Il s'agit en fait de porter WPF sur le Web et de faire ainsi converger applications "desktop" et applications Web de façon transparente. Mais Silverlight est aussi un merveilleux outil pour écrire des jeux en ligne (ou même desktop grâce à la fonction Out-Of-Browser). Plus loin, et j'en parle souvent, les techniques visuelles du jeu ne sont pas à négliger pour créer des applications professionnelles disposant d'interfaces innovantes.

Raison de plus pour se pencher sur la question. Dans les jours passés je vous ai parlé de la gestion du son (notamment en vous proposant un petit composant capable de rendre possible la synchronisation son/animation - AnimatableSoundPlayer. Ou comment synchroniser du son sur une animation Silverlight et Animations, Sons, Synchronisation, Ease in/out sous Blend), aujourd'hui je vais aborder la gestion du clavier. Pour ce qui est de la boucle de jeu, je vous renvoie à mon billet exposant l'exemple de la neige qui tombe (« Il neige » ou les boucles d’animation, les fps et les sprites sous Silverlight ).

D'abord un petit exemple live. Une fois que vous aurez cliqué sur le rectangle "click here to start" vous pourrez déplacer le carré rouge et changer sa taille. Les déplacements se font à l'aide des 4 flèches de direction. Pour agrandir l'objet on utilise la combinaison de touche Shift-KeyUp (et Shift-KeyDown pour diminuer la taille). La touche Ctrl est un accélérateur pour les mouvements. Ctrl-KeyUp/Down/Left/Right permet donc d'aller plus vite. Ce qui est intéressant dans cet exemple est bien entendu la détection des appuis simultanés sur les touches et la gestion de ceux-ci. Jouer deux secondes et on y revient :

[silverlight:source=/SLSamples/KeyTrapper/KeyTrapper.xap;width=400;height=400]

Tout le problème ici est donc de détecter plusieurs touches appuyées en même temps. Silverlight propose une gestion de clavier très simple : les événements KeyDown et KeyUp. Avec ça il faut se débrouiller.

Pour une gestion de déplacement rudimentaire (les 4 directions par les 4 flèches) cela pourrait parfaitement convenir. Mais comment gérer les déplacements en diagonal (KeyUp+KeyLeft par exemple) ou pire des choses du genre Shift-Ctrl-KeyUp/Barre d'espace ? Il faudrait se rappeler dans l'événement KeyDown si l'une ou l'autre des touches a été enfoncée et si elle est toujours Down... De plus aucune assurance de l'ordre dans lequel les touches vont arriver (la simultanéité n'existe pas du point de vue du pilote clavier, une touche est forcément avant l'autre).

Bref cela semble d'un seul coup se compliquer énormément !

Oui et non. Oui puisque la solution n'est pas directe, non parceque celle-ci n'est pas si compliquée à trouver.

La classe KeyLogger

Ne cherchez pas dans l'aide du Framework Silverlight, cette classe n'existe pas :-) Il s'agit justement de la classe que je vous propose aujourd'hui de créer pour gérer le petit problème des touches simultanées.

Problématique

On doit pouvoir à tout moment dans la boucle principale du jeu tester si certaines combinaisons de touches sont actives ou non. On doit aussi pouvoir tester l'appui sur une seule touche.

Solution

Il n'y a pas de miracle, pour savoir si une ou dix touches sont appuyées il faut se souvenir de toutes les touches ayant reçu un KeyDown et pas encore de KeyUp. Se souvenir, en informatique, cela signifie stocker des données. C'est bien ce que nous allons faire en créant un tableau dont les éléments seront des booléens et dont l'index sera la valeur de l'énumération Key (classe du Framework listant les touches accessibles du clavier). Ne reste plus qu'à gérer nous-mêmes les KeyUp et KeyDown pour mettre à vrai/faux les cases correspondantes dans le tableau. Pour tester une combinaison de touches (ou une touche) il suffit alors d'interroger le tableau pour savoir si les touches que nous voulons tester sont toutes à true.

Le code

Une fois le problème et la solution posés, il ne reste plus qu'à coder. Plutôt que d'alourdir ce post, je vous renvoie au code source du projet téléchargeable en fin de billet. Ouvrez-le sous Blend ou Visual Studio, vous comprendrez rapidement comment il fonctionne.

Le UserControl principal de l'application exemple commence par créer une instance du KeyLogger et l'attache à lui-même. On pourrait fort bien attacher un KeyLogger différent à différentes zones écran, ici nous optons pour un seul gestionnaire centralisé.

La détection du clavier ne marche que si le contrôle a le focus. Donner par défaut celui-ci au UserControl n'est pas forcément évident, je n'ai pas trouvé de solution qui marche systématiquement. D'où la petite astuce du bouton de démarrage : en cliquant dessus je lance l'animation qui le fait disparaître et qui diminue l'opacité des instructions mais surtout j'en profite de réclamer le focus. Cette technique a l'avantage de fonctionner à tous les coups.

Conclusion

Remplacer le rectangle rouge par une petite fusée, ajoutez des blocs rocheux, détectez la barre d'espace pour tirer, utilisez la gestion de sprites pour animer les tirs de laser, agrémentez d'une gestion de collision, complétez par une gestion de l'inertie des mouvements... et vous aurez une réplique de Asteroid ! Yaka. :-)

Déplacer des objets ou contrôler des animations via le clavier est l'une des bases de la création de jeux. Avec l'exemple de la neige qui tombe nous avions déjà vu la gestion des sprites, vous disposez maintenant des briques pour commencer à réfléchir à des petits jeux sympas (éviter la cent-millième version de Asteroid ou de Space Invader bien entendu :-) )!

Amusez-vous bien, et .... Stay Tuned !

Code source du projet de la classe KeyLogger : KeyTrapper.zip (78,30 kb)

AnimatableSoundPlayer. Ou comment synchroniser du son sur une animation Silverlight

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 09 Sep 2009 06:38:00 +0200

Hier je vous parlais d'animation et de sons et je vous présentais une petite démonstration (l'oscilloscope) dont le but était de montrer qu'on pouvait rapidement obtenir un effet visuel assez complexe sans programmation pour peu qu'on se donne la peine d'utiliser Blend et ses neurones... Pour synchroniser le bip avec le spot lumineux j'avais alors utilisé une ruse en indiquant qu'hélas Silverlight ne permettait pas de synchroniser du son dans une animation.

Je vous proposais alors une idée de solution en promettant une implémentation le temps de vous laisser réfléchir.

Regarder d'abord la démo ci-dessous. En cliquant sur "Start" vous lancerez une animation (StoryBoard) dont le but premier est de déplacer la boule verte un peu comme dans un billard. Elle rebondit sur des taquets pour finir dans un gobelet. Bien entendu tout cela est assez moche, les beaux dessins ne font pas partie de la question :-) Mais, en revanche, et si votre carte son fonctionne, vous noterez que plusieurs sons peuvent être entendus en parfaite synchronisation avec les "chocs" de la boule sur les taquets ou dans le gobelet final. Je vous laisse essayer et on en reparle :

[silverlight:source=/SLSamples/SyncSound/SyncSound.xap;width=251;height=242]

Bon. Vous avez vu et aussi entendu ?

Comment est-ce possible (sachant que pour l'utilisateur Blend qui créé l'animation tout cela ne réclame aucun code) ?

Forcément il y a du code... En fait un petit UserControl dont le principe est fort simple.

AnimatableSoundPlayer

C'est son petit nom. Un joueur de sons animable. Joueur de sons car ce UserControl n'a pas de visuel. On pourrait en réalité jouer des vidéos de la même façon il suffirait de relooker le contrôle, mais ce n'était pas le but. Joueur de son animable car ce qui manque au MediaElement c'est bien d'avoir des propriétés "animables" pouvant être modifiées sur une timeline.

Le UserControl AnimatableSoundPlayer est ainsi une coquille presque vide, il ne contient qu'un MediaElement. Tout le reste est du code, fort peu en réalité.

Dans un premier temps j'ai ajouté plusieurs propriétés de dépendance qui relaient les propriétés du MediaElement : la Source (une Uri), le Volume, etc. Ensuite j'ai fait de même pour les principales méthodes (Play, Stop...).

Deux choses ont été ajoutées. Côté méthodes j'ai créer PlayFromStart(). Elle ne fait que faire "Stop(); Play();". C'est tout bête mais très souvent on a besoin d'enchaîner ces deux méthodes pour s'assurer qu'un son est bien rejouer depuis le début, il faut rembobiner la bande avec Stop() pour réécouter un son.

La seconde chose ajoutée est la plus importante. Il s'agit de la propriété de dépendance AnimatablePlay de type double. Pourquoi double ? Simplement parce Silverlight sait animer des doubles et par forcément autrechose... Le mécanisme intéressant se trouve dans la méthode AnimatablePlayChanged, le callback de modification de la valeur initialisé lors de la création de la propriété de dépendance. A l'intérieur de ce callback nous trouvons la logique de cette propriété :

   1:  #region AnimatablePlay property

   2:          /// <summary>

   3:          /// Gets or sets the animatable play.

   4:          /// Value = 0 means <see cref="Stop"/>

   5:          /// Value sup.to 0 means <see cref="PlayFromStart"/>

   6:          /// Value inf.to 0 means <see cref="Play"/> / <see cref="Pause"/>

   7:          /// </summary>

   8:          /// <value>The animatable play.</value>

   9:          [Category("Media")]

  10:          public double AnimatablePlay

  11:          {

  12:              get { return (double)GetValue(AnimatablePlayProperty); }

  13:              set { SetValue(AnimatablePlayProperty, value); }

  14:          }

15:

  16:          public static readonly DependencyProperty AnimatablePlayProperty =

  17:              DependencyProperty.Register("AnimatablePlay", typeof(double),

  18:              typeof(SynchedSoundPlayer), new PropertyMetadata(0.0d, AnimatablePlayChanged));

19:

  20:          private static void AnimatablePlayChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

  21:          {

  22:              var mp = ((SynchedSoundPlayer)d);

  23:              if ((double)e.NewValue > 0d) mp.PlayFromStart();

  24:              if ((double)e.NewValue == 0d) mp.Stop();

  25:              if ((double)e.NewValue < 0d)

  26:              {

  27:                  if (mp.internalMP.CurrentState == MediaElementState.Playing) mp.Pause();

  28:                  else mp.Play();

  29:              }

  30:          }

31:

  32:          #endregion

Simple et efficace : toute valeur positive déclenche un "PlayFromStart", d'où l'utilité de cette méthode qui nous assure que le son est bien rejoué depuis le début. Toute valeur nulle appelle "Stop" et toute valeur négative entraîne un cycle Play/Pause selon l'état actuel du contrôle.

Le UserControl relaie aussi l'événement MediaFailed si on désire être prévenu en cas de difficulté rencontrée par le MediaElement pour charger le son (qui peut être dans le Xap comme dans la présente démo ou sur un serveur distant).

Grâce à cette convention il devient très simple de synchroniser des sons avec une animation !

Si on suit l'exemple live proposé plus haut : Trois sons sont joués, un numéro est indiqué sur chaque "obstacle" pour mieux se repérer. Sur ces trois sons il y en a un qui utilisé deux fois. Pour synchroniser ces trois sons on reprend la timeline de la boule verte et à chaque fois qu'on désire qu'un son soit joué on incrémente sa propriété AnimatablePlay. Simple. Vu la taille des valeurs maximales d'un double, on ne risque pas de tomber sur une limite... surtout qu'il n'est pas interdit de faire un retour à zéro quand on le veut.

Un petit détail à savoir : quand on créé une animation, par défaut Silverlight effectue une interpolation des valeurs fixées dans les keyframes qui se suivent. Si vous tapez la valeur 1 à la frame A et que vous tapez 2 à la frame B, durant le temps qui sépare A de B la valeur augmentera progressivement de 1 vers 2. C'est le comportement par défaut, ce qui est bien utile puisque justement le plus souvent on désire avoir une continuité dans le changement des valeurs (déplacements notamment). En revanche il y a des cas où on préfère que la valeur change brutalement, une "anti animation" en quelque sorte. Cela est parfois utile. Pour utiliser AnimatableSoundPlayer ce n'est pas une option, c'est une obligation. Il faut que les valeurs ne changent que lorsqu'une nouvelle keyframe est rencontrée. Sinon le son sera rejoué sans cesse depuis le début à toutes les valeurs intermédiaires, ce qui n'est pas du tout l'effet recherché.

Pour arriver à ce résultat il suffit de ne pas oublier de paramétrer les keyframes servant à animer le son afin qu'à la place d'une EasingDoubleKeyFrame le type devienne DiscreteDoubleKeyFrame. Sous Blend il suffit de cliquer sur la keyframe en question et de la passer en mode "Hold in". C'est la seule contrainte du composant.

Et voilà ! Avec un peu d'imagination on peut parfaitement créer un composant réutilisable qui ne prend que quelques lignes de code et qui permet de synchroniser du son dans une animation Silverlight. C'est pas magique ?

Je suis certain que vous trouverez des tas d'améliorations à porter au composant, alors n'hésitez surtout pas à m'en faire part je pourrais même diffuser vos versions modifiées si vous le voulez.

Le code du projet fourni contient l'exemple complet ainsi que le code du composant et les sons utilisés.

Quelques restrictions : Si vous modifiez le code obligez vous à publier le code source de votre version gratuitement. Si vous publier un article ou un billet de blog, soyez sympa et indiquez le lien vers mon billet. Si vous utilisez mon code dans un projet, commercial ou non, dites le moi ça me fera plaisir.
Si vous respectez ce petit deal, alors faites ce que voulez du code. Dans la négative que les foudres du Grand Bug Céleste s'abattent sur vous et chaque octet que vous coderez jusqu'à la fin de vos jours (c'est bien horrible ça non ? ).

Enfin bon, dans tous les cas, si vous en voulez encore du Silverlight, vous connaissez le refrain : Stay Tuned !!!

Le code du projet : SyncSound.zip (209,05 kb)

Animations, Sons, Synchronisation, Ease in/out sous Blend

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 08 Sep 2009 23:45:00 +0200

Effets visuels et sonores font partie des nouveaux éléments avec lesquels le concepteur de logiciel doit apprendre à jouer pour créer des interfaces attrayantes. Les réflexes du développeur le porte à se jeter sur son clavier, tout comme ceux du graphiste le pousse à sortir son bloc et son crayon. Comme tout réflexe il faut savoir s'en méfier...

Prenons l'exemple de l'affichage ci-dessous qui simule un oscilloscope :

[silverlight:source=/SLSamples/MovingSpot/MovingSpot.xap;width=288;height=237]

(passez la souris sur "settings" pour ouvrir la fenêtre de paramètres qui permet de jouer sur la lumonisité des carrés de ciblage, le flouté du spot et sur le volume du bip)

Pour créer l'effet du spot et de ses échos visuels le développeur aura donc tendance à se ruer sur son clavier et, s'inpirant des sprites (voir mon billet sur la création d'un effet de neige), il voudra créer une classe pour le spot, puis recherchera la formule mathématique de la courbe du déplacement du spot pour animer ce dernier, les échos étant créés à la volée avec une animation d'opacité décroissante. Tout cela va fonctionner parfaitement. Au bout du compte on disposera même d'un véritable affichage de type oscilloscope réutilisable avec des courbes différentes.

Mais s'agissant juste d'un affichage, d'un effet visuel, n'est-ce pas un peu lourd ?

On peut en effet réaliser la chose bien plus rapidement et sans avoir de debug à faire (puisque pas de code) si on "pense" design, pur dessin. Et au lieu d'ouvrir Visual Studio, ouvrons Blend...

Bien plus que l'exemple lui-même (assez simple) c'est cette démarche sur laquelle je souhaite attirer votre attention.

Côté réalisation comment cela se passe alors ? Deux contraintes nous sont données : animer un spot selon une courbe "réaliste" et avoir un rendu de la rémanence de l'écran. Prenons le déplacement pour commencer: il suffit de positionner un cercle à gauche de l'écran de l'oscilloscope (une image réalisée sous Design), d'ouvrir un StoryBoard et de créer une keyframe à 2 secondes du début puis de déplacer le cercle jusqu'à le faire sortir de l'écran. Le mouvement horizontal est réglé. Concernant le mouvement vertical et la simulation d'une courbe amortie, l'astuce consiste à déplacer en début d'animation le spot sur l'axe Y pour le faire monter. C'est tout, l'effet de courbe sera rendu en utilisant astucieusement les nouveaux modes d'Ease in et out de Silverlight /Blend. Le point de déplacement Y sera doté d'un Quintic In pour amortir le mouvement, le dernier point de l'animation sera lui doté d'un Elastic Out avec 5 oscillations et un Spingness de -2. On peut bien entendu ajuster ces éléments à sa guise.

L'effet du déplacement est ainsi rendu sans développement. Bien entendu il s'agit d'un simple affichage qui n'effectue pas le rendu d'une "vraie" courbe passée en paramètre. Mais ce n'était pas ce qu'on voulait. Juste un effet visuel "réaliste" en y passant le moins de temps possible.

Pour l'écho visuel ? La ruse est un peu grosse mais elle passe plutôt pas mal : il suffit de copier le spot et son animation deux fois puis de décaler légèrement les timelines vers la droite. On change ensuite l'opacité du 1er et du 2d écho (de façon décroissante). L'effet est ainsi rendu sans aucun code.

Un oscilloscope plus vrai que nature ! Il ne lui manque que la parole pourrait-on dire. Justement, ajoutons un son pour "faire plus vrai" (disons plutôt "plus cinéma" car les vrais oscillos ne font pas de bip). Au départ on avait envisagé de lancer l'animation du spot en mode bouclage infini. Hélas les storyboards n'ont qu'un seul événement : Completed qui ne sera jamais déclenché en plus (puisque bouclage infini). Comment attraper le début de l'animation pour jouer le son et le synchroniser avec l'affichage du sport ?

Pas facile, et pas vraiment de solution pour l'instant. Mais il n'est pas interdit de faire marcher ses neurones ! Nous allons simplement supprimer le mode infini à la boucle d'animation du spot. Ensuite nous allons pouvoir gérer l'événement Completed de celle-ci. Dans le gestionnaire il suffira alors de relancer l'animation, on en profitera alors pour activer le son qui est placé dans un MediaElement (donc Stop() puis Play()).

Le son est maintenant synchronisé avec l'affichage.

Mais si le son devait être déclenché au milieu de l'animation ? Hmm.. Là nous serions un peu coincé je pense. Tout de suite le développeur dirait "ha je l'avais bien dit, si j'avais fait une gestion de sprite j'aurais presque fini!". Peut-être. Mais revenir à une animation pas à pas pour avoir la main n'est toujours pas ce qu'on veut.

Il est dommage que Silverlight ne puisse pas animer le play et le stop d'un MediaElement, c'est un point faible car un comportement largement utilisé sous Flash par exemple. Mais si tel était notre besoin, là encore, il serait possible de réfléchir un peu au lieu de repartir sur une animation pas à pas complexe.

Par exemple nous pourrions créer un petit UserControl possédant une propriété PlaySound (une propriété de dépendance bien entendu sinon elle ne sera pas animable) pouvant passer de 0 à 1 pour bénéficier de l'animation des Doubles sachant que seul le passage à la valeur exacte 1.0 déclenchera la séquence Stop/Play du MediaElement intégré. Dès lors ne resterait plus qu'à poser ce contrôle sur notre application et d'animer sa propriété PlaySound en la faisant passer de 0 à 1.0...

Voilà un bon exercice sur lequel je vous laisse vous amuser un peu. La solution dans un prochain billet !

Pour le reste de l'exemple il n'y a rien de bien compliqué. La petite fiche des settings est dessinée sous Expression Design, son titrage a été converti en Paths poru éviter d'avoir à intégrer la fonte à l'application Silverlight. Les sliders sont reliés aux propriétés qu'ils modifient par la nouvelle possibilité de binding élément à élément de Silverlight 3.

Pour le petit composant permettant de synchroniser le son dans une animation, je ne dirais qu'une chose : Stay Tuned !

J'allais oublier, le code du projet : MovingSpot.zip (91,58 kb)

La mer, les propriétés de dépendance et les user control's...

odahan.nospam@nospam.e-naxos.com (Olivier) — Sat, 05 Sep 2009 02:56:00 +0200

La mer... un souvenir qui va s'effacer jusqu'à l'année prochaine... Mais pour prolonger le plaisir nous avons Silverlight !

Et comment mieux rendre grâce à la Grande Bleue qu'en fabriquant un User Control la mettant en scène ? Et bien c'est ce que nous allons faire, ce qui permettra ludiquement d'aborder un problème épineux concernant les propriétés de dépendance sous Silverlight. Mais d'abord le visuel :

[silverlight:source=/SLSamples/LaMer/LaMer.xap;width=480;height=480]

La mer bleue, ou la mer rouge, au choix... et c'est bien ce choix qui va poser problème.

La base du UserControl

Concernant le composant lui-même je suis parti d'un UserControl vide créé pour l'occasion. A l'intérieur un Path dessiné avec l'outil plume. Ce path est dupliqué deux fois (ce qui donne donc 3 exemplaires au final). Les deux copies sont modifiées : l'une tassée en largeur, l'autre agrandie sur le même axe.

Un StoryBoard complète le tout : les trois vagues sont déplacées de gauche à droite, l'animation est mise en mode Auto-Reverse et boucle infinie. Pour un mouvement plus doux en début et fin j'ai ajouté un ease in/out choisi parmi les nouveaux modes offerts par SL 3.

Le tout est englobé dans une grid pour bénéficier du clipping, le layout root étant une ViewBox, mais cette partie là de la cuisine interne du composant n'est pas forcément la plus subtile. Pour terminer j'ajoute un rectangle sans bordure qui est placé en mode Stretch au fond du Z-Order, il servira a définir un éventuel background.

Jusqu'à là rien de bien compliqué, juste un peu d'imagination est suffisant.

Là où ça se complique c'est lorsqu'il faut gérer la couleur des vagues et celle du rectangle de fond...

Héritage et propriété de dépendance sous Silverlight

Pour terminer correctement le UserControl il faut en effet penser à son utilisation. C'est à dire à ajouter des propriétés qui permettront à l'utilisateur du contrôle (le développeur ou l'intégrateur sous Blend) de modifier ses caractéristiques sans avoir besoin, bien entendu, de bricoler le source du contrôle lui-même.

Ici, nous souhaitons pouvoir modifier la couleur des vagues et celle du fond. Parfait me direz-vous, cela tombe bien, un UserControl descend de Control qui lui-même définit deux propriétés on ne peut plus à propos : Foreground et Background. Il "suffit" de les surcharger.

En effet, "il suffit de". Yaka.

Première chose, ces propriétés sont dites de dépendance (dependency property). Voir à ce sujet mon article Les propriétés de dépendance et les propriétés jointes sous WPF (article à télécharger). Ces propriétés ne sont pas définies comme ce qu'on nomme aujourd'hui pour les différencier les "propriétés CLR", les propriétés habituelles. Je vous renvoie à l'article cité ici pour creuser la question si vous ne connaissez pas les propriétés de dépendance.

Dès lors, et telles que fonctionnent ces propriétés spécifiques de Silverlight et WPF, pour les surcharger il faut passer par un système de métadonnées autorisant l'affectation d'une méthode callback. Dans cette dernière il est facile de répercuter sur le visuel les changements de valeur de la propriété. L'override d'une propriété de dépendance est donc assez simple. Sous WPF. Et c'est là qu'est le problème.

En effet, tout à l'air tellement merveilleux sous Silverlight depuis la version 2 qui accèpte du code C#, qu'on en oublie que si tout le Framework .NET pouvait tenir dans quelques méga octets on se demanderait bien pourquoi l'installation du dit Framework pour une application classique (desktop) réclame des dizaines et des dizaines de méga octets... Y'a un truc. Y'a même une grosse astuce je dirais : forcément yapatou. En clair, le Framework Silverlight est un découpage chirurgical de haute précision pour donner l'impression que tout fonctionne tout en évitant 90% du code du Framework. Et il y a des petits bouts qui manquent, et parfois des gros !

Concernant les propriétés de dépendance, l'équipe de Silverlight a implémenté le principal mais a laissé de côté les subtilités. Les métadonnées sont par exemple moins sophistiquées. Mais il n'y a pas que les données qui ont été simplifiées, les méthodes aussi. Et de fait, en tout cas pour l'instant, il manque aux propriétés de dépendance Silverlight la possibilité de les surcharger.

Aie ! Comment réutiliser Foreground et Background définies dans Control et accessibles dans le UserControl s'il n'est pas possible de modifier les métadonnées et d'enregistrer notre propre callback ? J'ai longuement cherché car le problème est loin d'être évident à résoudre. Certains préconisent même face à ce problème de redéfinir vos propres propriétés. C'est tellement horrible comme solution que je m'y suis refusé. Comment avoir le courrage de définir une couleur de fond et une couleur d'avant plan au sein d'un composant visuel qui affichera fièrement de toute façon Foreground et Background qui n'auront, hélas, aucun effet ? Quant à faire une réintroduction de ces propriétés (avec le mot clé "new"), n'y pensez pas, j'ai essayé et ça coince un peu (par code ça marche, mais le XAML se fiche de la redéfinition et utilise toujours la propriété originale, ce n'est pas un bug mais une feature ou plutôt un effet assumé du fameux découpage savant dans le Framework).

J'avoue que pour l'instant cet oubli volontaire dans Silverlight me chagrine. Pourquoi l'équipe Silverlight, qui fait la chasse au gaspi un peu partout, s'est amusée à définir ces deux propriétés dans la classe Control si on ne peut pas en hériter, sachant que Control ne sert à rien d'autre qu'à créer des classes héritées ? C'est assez mystèrieux même si je suppose qu'il s'agit d'un problème de compatibilité avec WPF, Silverlight en faisant moins que son grand frère mais toujours en permettant que cela soit transparent pour le code. Bref, à satisfaire deux besoins opposés, d'un côté en coder le moins possible pour assurer la taille la plus petite au plugin et de l'autre assurer la compatibilité du code avec WPF, on finit par tomber sur des paradoxes de ce genre.

L'Element binding (ajouté dans SL 3) n'est pas utilisable non plus, à moins de donner un nom au UserControl (je veux dire à l'intérieur même de la définition de celui-ci). Ce qui n'est pas acceptable car si l'utilisateur du composant change ce dernier, le binding est cassé. Pire si l'utilisateur tente de placer deux instances sur une fiche, il y aura un conflit de nom. Solution inacceptable donc. J'ai testé, je pense, toutes les combines possibles. Mais j'ai enfin trouvé celle qui fonctionne !

La Solution

La piste de l'Element binding, nouvelle feature de SL 3, n'était pas mauvaise. Le problème c'est qu'en Xaml cela réclamait de pouvoir indiquer le nom de la source (le UserControl) alors même qu'à l'intérieur de la définition de notre contrôle il n'était pas question de lui donner un x:Name figé.

Mais en revanche, ce qui est possible en Xaml l'est tout autant par code (et souvent inversement d'ailleurs). Par chance, la classe permettant de définir un Binding n'utilise pas les noms pour la source ni le destinataire. Elle utilise les noms des propriétés mais là on les connait et ils ne changeront pas. Du coup, en définissant le Binding dans le constructeur (ou plutôt dans le gestionnaire de l'événement Loaded) on peut référencer "this", c'est à dire l'instance du UserControl, sans connaître son nom. On peut donc créer un lien élément à élément entre la propriété Fill des Path's et la propriété Foreground du UserControl (idem pour le Fill du rectangle et la propriété Background du UserControl).

Et ça marche ! Lorsqu'on compile tout ça et qu'on pose un composant "LaMer" sur une fiche on peut modifier la propriété Foreground et les vagues changent de couleur.

   1:          public LaMer()

   2:          {

   3:              // Required to initialize variables

   4:              InitializeComponent();

   5:              Loaded += new System.Windows.RoutedEventHandler(LaMer_Loaded);

   6:          }

7:

8:

   9:          private void LaMer_Loaded(object sender, System.Windows.RoutedEventArgs e)

  10:          {

  11:              // l'astuce est là !

  12:              var b = new Binding("Foreground") { Source = this, Mode = BindingMode.OneWay };

  13:              Vague1.SetBinding(Shape.FillProperty, b);

  14:              Vague2.SetBinding(Shape.FillProperty, b);

  15:              Vague3.SetBinding(Shape.FillProperty, b);

16:

  17:              var bb = new Binding("Background") { Source = this, Mode = BindingMode.OneWay };

  18:              rectBackground.SetBinding(Shape.FillProperty, bb);

19:

  20:              VaguesAnim.Begin();

  21:          }

Pour le Background on fait pareil avec le rectangle. Mais, allez-vous me dire (si si, vous y auriez pensé, un jour :-) ), pourquoi aller mettre un rectangle pour obtenir une couleur de fond alors même qu'il y a déjà une grille en dessous ? La grille possède aussi une propriété Background. Pourquoi, hein ?

La réponse est simple, j'ai forcément essayé, et ça fait un magnifique plantage avec une erreur dont le message fait peur en plus (du genre "anomalie irrémédiable dans cinq secondes tout va sauter, non ça a déjà sauté!"). Le message d'erreur étant assez peu clair quant aux raisons du plantage j'ai fini par abandonner. Ce qui marche une ligne avant pour la propriété Fill des rectangle avec la propriété Foreground du UserControl ne fonctionne pas du tout pour le Background de la grille liée au Background du UserControl. Là, ce n'est pas une feature, je penche sérieusement pour un gros bug.

Cela étant donné, j'ai donc ajouté un rectangle en fond pour qu'il puisse justement servir de ... Background. Et là ça passe. Ouf !

Ouf !

Silverlight c'est génial, c'est tout .NET et tout WPF dans un petit plugin. Mais dès qu'on sort du carré de verdure, on tombe dans les bois et là des loups il y en a quelques uns qui vous attendent au tournant ! Cela est logique, on s'y attend, c'est le prix à payer pour avoir .NET dans un browser Internet. Forcément le costume est un peu serré, le tissu a été économisé. Mais cela ne change rien à l'amour qu'on porte à Silverlight, au contraire, on se rend compte ainsi à quel point le travail de l'équipe Silverlight a été (et est encore) un véritable casse-tête et à quel point ils ont réussi un tour de force en faisant entrer un éléphant dans une boîte d'allumettes... Tout de même, une fois arrivé à la solution j'ai poussé un grand Ouf!

Le code source du projet : LaMer.zip (62,54 kb)

Pour de nouvelles aventures : Stay Tuned !

Les ChildWindow's de Silverlight 3

odahan.nospam@nospam.e-naxos.com (Olivier) — Fri, 04 Sep 2009 03:07:00 +0200

Parmi les nouveautés de Silverlight 3 se trouve la classe ChildWindow. Elle permet de créer facilement en quelques clics un dialogue modal, le tout avec animation.

Savoir se servir de cette classe ne réclame pas forcément des pages entières d'explication, alors justement m'est venu l'idée d'en faire un tutor video...

C'est au visionnage de cette video que je vous invite pour comprendre comment utiliser cette nouvelle feature de Silverlight 3.

(le son micro n'est pas terrible, pour la prochaine video j'utiliserai autre chose de mieux ! Une astuce : double cliquez sur la video pour passer en plein écran. Sorry, la définition est assez basse mais le fichier avi fait déjà 30 Mo et l'original non compressé fait plus de 9 Go ... Je vais voir comment améliorer tout ça pour la prochaine fois, promis !).

Techniquement, la vidéo est hébergée sur Silverlight Streaming et c'est par le biais d'un plugin Silverlight géré par ce site que la vidéo peut être visionnée.

Bonne vidéo !

Le défit des nouvelles interfaces Silverlight et WPF - La cassure conceptuelle

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 01 Sep 2009 18:55:00 +0200

J'ai l'habitude de publier ici du code, des tutors et des informations qui sont majoritairement très techniques. Il y a certains sujets où il me semble bon de prendre un peu de recul, les nouvelles interfaces utilisateurs le méritent largement. En effet, l'avalanche à la fois technologique et visuelle qui accompagne Silverlight et WPF, peut faire oublier l'objectif réel et le changement de paradigme, le nez collé à la vitrine, la tête dans le guidon pour ingurgiter les propriétés de dépendance ou les RIA Services on ne prend pas assez le temps de réfléchir plus globalement...

Ce billet sera donc une pause dans ce rush, on s'assoit, on prend le temps de réfléchir.

Pourquoi "nouvelles" interfaces ?

Comme vous l'avez certainement compris, quelque chose a changé. Il suffit de regarder Surface et son interface pour comprendre que ce changement n'est pas uniquement cosmétique, il est profond et touche aussi bien à la représentation des données qu'à l'interaction homme / machine. C'est pourquoi je parle ici de "nouvelles" interfaces utilisateur.

N'est-ce qu'une question de mode ?

Oui et non.

Oui car tout est mode chez l'humain... La façon de se coiffer, de s'habiller, la forme des voitures, celle des cafetières, etc. L'informatique, dans sa partie visuelle et interactive n'échappe pas à ce mouvement perpétuel. Le fait qu'un programme puisse se manipuler selon des concepts "à la mode" n'est donc pas "honteux" ni même accessoire ! C'est ainsi que l'humain vit, c'est ainsi qu'il imprime sa marque à l'environnement qui l'entoure.
L'humain est le seul animal a modifier son environnement pour le faire correspondre à ses rêves, là où tous les autres animaux subissent de plein fouet la sélection darwinienne et ce qu'on appelle la pression de l'environnement sans rien pouvoir y changer. Il y a donc bien un phénomène de mode dans ces "nouvelles interfaces" mais nous venons de voir que mode et civilisation humaine sont deux choses inséparables...

Non car on a tendance à associer les modes à la simple cosmétique et que le changement qui s'opère est bien plus conceptuel qu'un simple "relookage". J'y reviens plus loin.

Qu'est-ce qu'une mode ?

Pour ce qui nous intéresse ici, car sinon on pourrait en faire largement un sujet de thèse, disons qu'une mode est une façon collective et temporaire de faire les choses ou de les représenter.

Comment passe-t-on d'une mode à l'autre ?

Pour l'illustrer, une petite anecdote :

J'étais chez mon père il y a quelques jours et il venait de s'acheter une machine à café Senseo (lassé qu'il était de se faire racketter par les dosettes Nespresso du bellâtre "What else?"). Surprise ! ce modèle est rectangulaire alors que les Senseo, jusqu'à lors, était tout en rondeur (le nouveau modèle n'est d'ailleurs même pas encore sur leur site). Un changement de mode s'opère... Mais comment ? Ici on le voit, la mode était aux rondeurs, elles semblent passer aux formes plus carrées. Il est de même en informatique : Windows nous a habitués à ses débuts à des fenêtres bien rectangulaires aux angles bien droits. Ces fenêtres plates et rectangulaires ont fini par lasser. Windows avec XP et plus encore avec Vista et 7 est donc passé aux rondeurs. La "classe" absolue ayant été au début de cette mode de faire tourner ses applications dans une fenêtre non rectangulaire ! Allons-nous revenir à des fenêtres rectangulaires à l'instar des formes de la nouvelles Senseo ? Le nouveau paradigme qui préside à la conception des "nouvelles interfaces" se résume-t-il à cela ?

La cassure conceptuelle

De nombreuses modes en effet se sont juste résumées à cela : un changement de forme. Quand tout est rond on finit par revenir à quelque chose de plus carré et inversement. Le triangle, malgré sa très grande force symbolique ne se prête guère à l'affichage écran. Exit le triangle, le losage n'étant guère plus pratique, peut-être qu'un jour la mode sera aux fenêtres patatoïdes !

Les nouvelles interfaces homme / machine se situent-elles uniquement sur le plan esthétique ?

Encore une fois : Oui et non.

Oui car il est impossible pour une représentation d'échapper à la mode ambiante, ou celle à venir. Il en va de même en écriture par exemple.
On peut écrire des choses très nouvelles sur un sujet, mais il faudra bien se plier aux exigences de la langue de son pays, telle qu'elle est parlée au moment où l'on écrit.
On voit mal un philosophe contemporain ou même un simple romancier publier un ouvrage en latin ou en vieux français. Certains mots sont plus "à la mode" que d'autres, et s'il ne veut pas que sa prose "sente la naphtaline" il faudra qu'il emploie les mots, expressions et formes grammaticales de son temps.
Sinon il risque tout simplement de ne pas être lu/écouté, pire de ne pas être compris. Car la mode est un code culturel qui fait partie intégrante de la communication et donc de la compréhension entre l'émetteur et le récepteur d'une information.
Il y a donc toujours une part d'allégeance à la mode en cours dans toute forme de communication. Cette mode pouvant même varier au sein d'une même société selon la cible visée (on ne s'adresse pas à la célèbre ménagère de moins de 50 ans des sondages comme à l'ado qui écrit en langage texto).
La mode, ainsi exprimée, s'intègre dans un corpus de règles sociales et morales plus large qu'on appelle les us et coutumes. Vouloir y échapper n'est pas forcément faire preuve d'originalité. Refuser la mode par simple réaction c'est aussi se couper de ses contemporains. Mais on peut aussi créer la prochaine mode...

Non car on assiste aujourd'hui à une cassure conceptuelle. Une rupture qui peut largement être minorée, voire ignorée, cachée qu'elle est, justement, derrière l'écran de fumée du simple phénomène de mode perçu comme seule modification esthétique.

Quelle est cette cassure conceptuelle ?

Elle est de taille ! Prenons un exemple concret : vous devez créer un logiciel de surveillance bancaire. Ici tout n'est que séries de chiffres, de pourcentages, de tendances à la hausse ou la baisse. Comment allez-vous créer l'interface d'un tel logiciel ?

La plupart des informaticiens se plongeront d'abord dans le code et poseront ensuite rapidement quelques grilles, ces horribles tableaux rectangulaires que tout éditeur de composants se doit d'avoir perfectionné à sa manière.

Va-t-il suffire de "templater" une DataGrid sous Blend en lui mettant des coins arrondis pour dire qu'on a utiliser correctement Silverlight ou WPF ?

Là, en revanche une seule réponse, claire et nette : Non !

Se servir du potentiel créatif de Silverlight et WPF ne consiste certainement pas à relooker les cases à cocher ni à "coller" un drop shadow à une boîte de dialogue ! Agir ainsi est un gâchis énorme, et surtout c'est ne pas avoir compris la cassure conceptuelle qu'impose ces outils.

Revenons à notre hypothétique application de surveillance. Supposons pour simplifier qu'elle permette à l'utilisateur d'avoir un oeil sur les actions de son portefeuille. La surveillance pouvant être activée ou désactivée pour chaque action.

La première tentation sera ainsi de représenter la liste des actions sous la forme d'une grille de données. On aura l'impression de profiter de toute la technologie en templetant la grille pour ajouter le logo de la société, des petites pastilles qui changent de couleur quand le logiciel teste une action, une autre quand l'action est à la hausse ou à la baisse, etc. On ira même jusqu'à ajouter quelques animations, c'est tellement "fun". L'utilisateur naviguera entre les pages qui coulisseront à l'écran de droite à gauche et réciproquement, etc. Là on aura eu l'impression de faire du neuf et d'exploiter à fond les possibilités de Silverlight/WPF !

Hélas, que nenni... En réalité ce qui aura été fait n'aura concerné que la seule apparence. Mettre du rond là où c'était habituellement carré ou l'inverse. C'est la mode dans son sens le plus négatif et le plus péjoratif qui soit : une lubie temporaire qui fait que si on n'a pas les dernières Nike en cour de récré on passe pour un ringard à qui plus personne ne veut parler. Angoisse permanente de l'ado moderne. C'est le côté agaçant, "fashion victim", la mode pour la mode, écervelée. Pourquoi ? Parce que la mode sans un vrai concept n'est rien.

La force du concept

Tout est concept, la réalisation n'est finalement que le passage obligé pour donner corps à un concept. Un compositeur quand il possède le concept, l'idée d'une nouvelle oeuvre, n'a pas besoin de savoir écrire des partitions ni même de savoir jouer d'un instrument. Le vrai acte de création est purement intellectuel. C'est un pur concept. Mais pour le communiquer à ses semblables il lui faudra passer par la réalisation. Souvent d'ailleurs un compositeur fera appel à un arrangeur pour tout ou partie de son oeuvre. Par exemple quelqu'un qui est spécialisé dans les parties de violons ou dans celles des cuivres. Tout le monde n'est pas Mozart, ce qui n'empêche pas des tas de compositeurs d'être connus et reconnus. Pour les films il en va de même. L'auteur n'est que rarement le réalisateur, et encore moins souvent le dialoguiste. Cela enlève-t-il de la valeur à son manuscrit sans qui le film n'existerait pas ?

Le passage au tout conceptuel est justement l'apanage de l'art contemporain. Certains y voient une fumisterie car ils n'ont pas compris qu'ici la cassure a eu lieu : la réalisation n'est que la partie visible de l'iceberg, l'essentiel de l'oeuvre se trouve dans le ... concept. C'est pourquoi le bonhomme à tête carré dessiné par votre fils de 5 ans n'a aucune valeur autre que sentimentale alors que celle d'un Picasso s'arrache à coup de millions de dollars (même si ici la spéculation purement financière vient gâcher toute la beauté de l'art, mais c'est encore un autre sujet!). Picasso n'est pas un handicapé moteur ne sachant pas faire mieux que des têtes carrées, il dessine à merveille, comme un Dali ou un Miro. Mais il a choisi de casser le moule, de s'exprimer autrement en échappant au carcan normatif, et pour cela il a beaucoup réfléchit ! Le changement est principalement et purement conceptuel, bien avant d'être dans le geste du pinceau sur la toile.

Une autre représentation du monde

Revenons à notre application bancaire. Que c'est triste comme sujet... Même relooké sous Blend, que cet étalage de chiffres sera rébarbatif. N'y-a-til pas moyen de casser le cadre, d'échapper au carcan normatif ? Ne peut-on pas ajouter quelques grammes de douceurs dans ce monde de brutes ? Un poil de poésie ?

Si, cela est possible. A condition de re-conceptualiser le rapport homme / machine, et donc les interfaces.

Un peu de poésie

Très honnêtement la bourse n'est pas un sujet qui m'inspire beaucoup de poésie mais faisons un effort !

Dans notre exemple chaque action se singularise par un nom, une quantité possédée, un cours et par un indicateur signalant si elle est surveillée ou non.

Transformons ces données en acteurs. Car le changement conceptuel est en partie là. Chaque action sera ici un acteur autonome. Ne nous reste plus qu'à choisir comment cet acteur sera représenté et dans quel univers on va le faire vivre.

Par contraste choisissons un cadre naïf à l'opposé du monde de la finance : une scène champêtre. Notre décor sera une clairière avec une forêt en arrière plan. La tendance du CAC40 ? Nous allons la représenter par le temps qu'il fait : ciel bleu neutre quand l'indice est stable, soleil caniculaire lorsque que l'indice dépasse un certain pourcentage de hausse par rapport à la veille, pluie voire tempête lorsque l'indice se casse la figure.

Voilà déjà une information conventionnelle et rébarbative représentée d'une autre façon, non conventionnelle. Imaginez-vous un écran géant, quelque part sur un mur du bureau. Un joli décor de campagne animé. Quelques nuages arrivent dans le ciel. L'oeil averti de l'utilisateur saura que le CAC40 est en baisse légère. Avec l'habitude, en comptant les nuages dans le ciel il saura même dire de combien de pourcent. Tout cela sans datagrid ni alignement de chiffres....

Mais poussons plus loin les choses et intégrons les actions à ce paysage.
Supposons que chaque action soit représentée par un animal qui va évoluer dans le décor.
Total, ce goinfre, sera peut-être representé par un sanglier fouillant le sol. Air France sera représenté par une libellule, les Ciments Lafarge par un castor, etc. Maintenant appliquons à ses animaux des comportements en fonction des données chiffrées. Le nom n'est plus une donnée à affichée, le caractère choisi pour chaque action est une identité. Une donnée de moins à afficher. La quantité d'action sera représentée par la position de l'animal : à l'avant-plan quand on possède beaucoup d'action de ce type, loin quand on en possède peu. Encore une colonne du data grid qui devient inutile. Le cours est-il à la hausse ou la baisse que l'animal aura un comportement joyeux, bondissant dans le décors, ou bien qu'il semblera mou, figé, voire couché sur le flanc au sol. Plus besoin de datagrid !

Et le caractère actif/inactif de la surveillance d'une action ? Imaginons un enclos dans le décor. Par simple Drag'drop (avec le doigt comme sur Surface) prenons un animal et posons-le dans l'enclos. Le logiciel interprètera cela comme l'exact effet d'une case à cocher "surveillance active" qui sera décochée. Reprendre l'animal et le sortir de l'enclos aura l'effet inverse.

Une idée folle ?

Fermez les yeux et imaginez ce tableau vivant un instant... Une scène de campagne avec des petits animaux qui se promènent, le temps qui change, ah, tiens, une éclaircie. Le pauvre castor a l'air bien malade se matin...

Bien entendu, certains voudront savoir ce que j'ai fumé aujourd'hui, c'est un risque que j'ai pris et que j'assume en écrivant ce billet :-)

Mais ce que nous venons de faire ici est de transformer une application rébarbative qui, dans le meilleur des cas aurait été rendu sous la forme de tableaux de chiffres aux coins arrondis servis par quelques boutons animés et une poignée de drop shadow, en une scène champêtre, charmante. Quelque chose qui donne envie de regarder le programme fonctionner juste pour le plaisir. Car les données sont devenues des acteurs, car le cadre du programme est devenu un univers auto-suffisant.

La cassure est là

Plus de cases à cocher, plus de colonnes de chiffres, plus rien de normatif ni conventionnel. Les données sont des acteurs autonomes qui racontent une histoire.

Est-ce si fou ?

Il est évident que l'exemple que j'ai pris des cours de la bourse et sa représentation gentillement niaise façon Walt Disney est un simple contrepied volontairement ironique, mais pas seulement. Imaginez-vous encore ce joli tableau dans le bureau d'un riche spéculateur... Ne pensez-vous pas que je pourrais vendre des installations complètes, très cher, et que cela marcherait ? Certainement que si. Alors que personne ne voudrait acheter le énième logiciel de gestion de portefeuille que je pourrais écrire, même relooké sous Blend ! Certains même parleraient alors de snobisme, de gadget. Ceux qui ne pourraient s'offrir mon système bien entendu. Mais pas les utilisateurs qui l'achèteraient et qui en seraient très contents ! La "mode" serait lancée !

Ce qu'il faut donc comprendre ici c'est que les "nouvelles interfaces utilisateurs" l'UX (User eXperience), ce nouveau paradigme dont je parle ici bien souvent et depuis un moment maintenant, n'est pas "qu'une mode", c'est un changement conceptuel, donc en profondeur, du rapport entre l'homme et la machine. C'est une nouvelle façon de penser les données non plus comme des informations passives mais comme des acteurs autonomes évoluant dans un univers vivant.

Et concrètement ?

Tout cela est bien gentil, mais certains se disent (les plus courageux, ceux qui sont arrivés jusqu'à cette ligne ! - merci au passage :-) ) que bon, ils ont un soft à faire pour hier et qu'ils voient mal comment tout ce gentil délire peut s'appliquer à une compatibilité analytique ou une facturation.

Je leur répondrais que si j'ai pu tranformer, même virtuellement dans ces lignes, une application de gestion portefeuille boursier en une scène de campagne tout peut être fait !
Pourquoi ne pas transformer les comptes clients en bulles de couleurs évoluant dans un aquarium, plus la bulle est grosse plus l'encours du client est important, ou bien pour les commerciaux, plus la bulle devient grosse plus il est temps d'appeler le client car il n'a pas passé de commande depuis longtemps. Quelques jolis écrans plats sur les murs du service commercial ou dans le bureau du patron permettraient immédiatement de suivre la vie de l'entreprise, sans chiffres, sans cases à cocher ni boutons radio, sans fenêtre aux coins ronds ou non...

Application exemple

Dans mon temps perdu (autant dire pas grand chose) je suis en train de faire une petite application Silverlight qui met en pratique ces concepts pour faire comprendre comment on passe de mes explications à un vrai logiciel qui fait quelque chose de réel. Le code C# de l'application est déjà écrit et testé, c'est bien entendu le look qui prend le plus de temps dans un tel cas. Des mock-up en 3D, du sketching sur des bouts de papier, des dessins sous Expression Design, il me reste à mettre tout cela en forme sous Blend.

Un autre exemple existe depuis quelques années, il n'est pas logiciel mais bien du domaine informatique tout de même : le lapin Nabaztag. Tiens, il baisse l'oreille gauche... le CAC 40 se casse la figure. Ah, il devient rouge, ma chérie a laissé un message sur mon répondeur... Le créateur du Nabaztag a tout compris de cette cassure conceptuelle et des nouvelles interfaces utilisateur...

Si le sujet vous intéresse, et pour voir prochainement une illustration de ce que je viens d'expliquer ici, alors une seule solution :

Stay Tuned !

Silverlight et la sérialisation

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 25 Aug 2009 16:29:00 +0200

La sérialisation est un besoin fréquent que le framework .NET sait parfaitement gérer. La sérialisation binaire s'obtient d'ailleurs le plus naturellement du monde en ajoutant un simple attribut [Serializable] à la définition de la classe. Mais voilà, essayez de décorer une classe avec SerializableAttribute sous Silverlight... Surprise ! Un message d'erreur vous prévient que l'espace de nom ne peut être trouvé.

Pas de sérialisation ?

Non. Pas de sérialisation binaire en tout cas sous Silverlight jusqu'à maintenant (v 3.0 au moment de ce billet). La classe SerializableAttribute n'est tout simplement pas définie dans System.

Avant d'aller crier au scandale sur les blogs ou forums officiels essayons de réfléchir...

A quoi sert la sérialisation ?

Sérialiser, cela sert à prendre un "cliché" d'une instance dans le but d'être capable de recréer une copie parfaite de cette dernière au bout d'un certain temps.

Un certain temps... cela peut être une milliseconde ou bien 1 jour ou 1 an. Dans le premier cas le stockage du "cliché" est en mémoire généralement, mais dans le second, il s'agit le plus souvent d'un stockage persistant tel qu'un fichier disque ou une base de données.

Pas de gestion de disque local en RIA

La nature même de Silverlight et le style bien particulier d'applications qu'il permet d'écrire fait qu'il n'existe aucune gestion de disque local. En réalité il n'existe rien qui permette d'accéder à la machine hôte, en lecture comme en écriture, question de sécurité.

On notera quelques exceptions à cette règle : l'OpenFileDialog qui permet d'ouvrir uniquement certains fichiers sur les disques de l'hôte et l'IsolatedStorage, espace de stockage local protégé pouvant être utilisé par une application Silverlight. Toutefois OpenFileDialog ne règle pas le problème de persistance et si l'IsolatedStorage peut être exploité en ce sens il s'agit d'un espace restreint, inlocalisable par un utilisateur "normal" donc in-sauvegardable sélectivement. Autant dire que l'IsolatedStorage peut rendre des services ponctuels (cache de données principalement) mais que ce n'est certainement pas l'endroit où stocker des données sensibles ou à durée de vie un peu longue.

Bref, en dehors de ces exceptions qui ne règlent pas tout à fait le besoin de persistance des instances, une application de type RIA ne peut sérieusement gérer des données que distantes...

En tout logique...

Reprenons : la sérialisation sert à persister des instances pour un stockage à plus ou moins longue échéance ou une communication avec un serveur distant. La nature d'une application RIA supprime la liberté d'un stockage local fiable et facilement maitrisable.

En toute logique sérialiser des instances sous Silverlight n'a donc aucun intérêt, sauf pour communiquer avec un serveur distant.

Comme le framework .NET pour Silverlight est une version light du framework complet il a bien fallu faire des coupes sombres... La sérialisation n'a pas échappé à cette rigueur. La principale raison d'être de la sérialisation sous Silverlight étant la communication (quelle que soit la technologie cela se fait sur une base XML le plus souvent) et cela réclamant une sérialisation XML plutôt que binaire, SerializableAttribute et sa sérialisation binaire ont ainsi été "zappés" !

Une solution

La situation est grave mais pas désespérée. S'il reste difficile le plus souvent d'utiliser directement sous Silverlight des classes conçues pour le framework complet (et pas seulement à cause de la sérialisation binaire), il est tout à fait possible de sérialiser des instances sous Silverlight à condition d'utiliser les mécanismes qui servent aux communications avec les serveurs distants.

Le DataContract

Silverlight utilise une partie du mécanisme WCF du DataContract (mais l'attribut DataMember n'existe pas). On trouve même une classe le DataContractSerializer qui fournit le nécessaire pour sérialiser et désérialiser des instances même si celles-ci ne sont décorées d'aucun attribut particulier.

Au final la sérialisation sous Silverlight est plus simple que la sérialisation binaire par SerializableAttribute sous le framework complet !

Un exemple de code

Einar Ingebrigtsen, un MVP nordiste travaillant en scandinavie, à eu la bonne idée de proposer deux méthodes utilitaires qui montrent comment utiliser le DataContractSerializer. Plutôt que d'imiter et réinventer la roue, regardons son code :

   1:  public string Serialize<T>(T data)

   2:          {

   3:              using (var memoryStream = new MemoryStream())

   4:              {

   5:                  var serializer = new DataContractSerializer(typeof(T));

   6:                  serializer.WriteObject(memoryStream, data);

7:

   8:                  memoryStream.Seek(0, SeekOrigin.Begin);

9:

  10:                  var reader = new StreamReader(memoryStream);

  11:                  string content = reader.ReadToEnd();

  12:                  return content;

  13:              }

  14:          }

15:

  16:          public T Deserialize<T>(string xml)

  17:          {

  18:              using (var stream = new MemoryStream(Encoding.Unicode.GetBytes(xml)))

  19:              {

  20:                  var serializer = new DataContractSerializer(typeof(T));

  21:                  T theObject = (T)serializer.ReadObject(stream);

  22:                  return theObject;

  23:              }

  24:          }

C'est simple et efficace. Attention, pour utiliser ce code il faudra ajouter une référence à System.Runtime.Serialization.dll, puis un using System.Runtime.Serialization.

L'utilisation de ces méthodes tombe dès lors sous le sens, mais un petit exemple est toujours plus parlant :

   1:  { ....

   2:  // nouvelle instance

   3:  var t = new Test { Field1 = "test de serialisation", Field2 = 7 };

   4:  t.List.Add(new test2 { Field1 = "item 1" });

   5:  t.List.Add(new test2 { Field1 = "item 2" });

   6:  t.List.Add(new test2 { Field1 = "item 3" });

7:

   8:  // sérialisation et affichage

   9:  var s = Serialize<Test>(t);

  10:  var sp = new StackPanel { Orientation = Orientation.Vertical };

  11:  LayoutRoot.Children.Add(sp);

  12:  sp.Children.Add(new TextBlock { Text = s });

13:

  14:  // désérialisation et affichage

  15:  Var t2 = Deserialize<Test>(s);

  16:  var result = t2 == null ? "null" : "instantiated";

  17:  sp.Children.Add(new TextBlock { Text = result });

  18:  }

19:

  20:  // la classe de test

  21:  public class Test

  22:  {

  23:    public string Field1 { get; set; }

  24:    public int Field2 { get; set; }

  25:    private ObservableCollection<test2> list =

  26:                  new ObservableCollection<test2>();

  27:    public ObservableCollection<test2> List { get { return list; } }

  28:  }

29:

  30:  // la classe des éléments de la liste de la classe Test

  31:  public class test2

  32:  {

  33:    public string Field1 { get; set; }

  34:  }

Conclusion

Une fois que l'on a compris pourquoi la sérialisation binaire est absente de Silverlight, et une fois qu'on a trouvé une solution de rechange, on se sent beaucoup mieux :-)

Il reste maintenant tout à fait possible de stocker en local le résultat de la sérialisation dans un fichier texte (en utilisant l'IsolatedStorage sur lequel je reviendrai) ou bien de le transmettre à service Web ou autre...

Stay Tuned !

Bien commencer avec Silverlight 3 (les setup indispensables)

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 25 Aug 2009 01:24:00 +0200

Silverlight 3 est disponible depuis juillet dernier mais il n'est pas toujours évident de savoir exactement ce qu'il est nécessaire de télécharger et où pour bien commencer.

Les vacances sont passées par dessus tout ça, du coup vous n'avez pas forcément bien suivi l'action, alors pour vous voici en mode slow motion, le replay des indispensables à installer pour s'amuser comme un fou avec Silverlight 3 et surtout être au point pour concevoir des applications RIA !

Silverlight 3

Le runtime est indispensable pour, au minimum, pouvoir exécuter les applications : Le runtime Silverlight 3
Le SDK est en revanche le minimum syndical pour concevoir des applications Silverlight 3 : Le SDK Silverlight 3

Expression Blend 3 avec Sketchflow

Blend est un l'outil indispensable pour créer des applications WPF et Silverlight. D'autant plus que depuis la version 3 de Silverlight il n'y a plus d'affichage du visuel sous VS 2008. Il reste la possibilité de tout faire à la main en mode éditeur de XAML mais franchement ce n'est pas comme ça qu'on peut créer sérieusement un visuel alors : Blend 3 et Sketchflow
Vous noterez qu'il s'agit d'une version d'essai, Blend 3 n'a pas de version gratuite.

Visual Studio 2008

En attendant la version 2010 qui intègrera le designer visuel de Silverlight, il est toujours nécessaire de posséder VS 2008. En effet, Blend ne gère pas le debug qui ne peut s'effectuer que par VS. Bien qu'un éditeur de code a été ajouté à Blend 3 il est aussi plus confortable d'utiliser Visual Studio pour toute la partie code. Si vous ne possédez pas VS 2008 : Version d'essai de VS 2008

Visual Web Developer Express

Si vous préférez un outil gratuit, n'oubliez pas que Visual Web Express est une bonne alternative à Visual Studio.

Outils Silverlight

Tout un tas de choses indispensables notamment pour permettre de travailler sous Visual Studio ou Visual Web Express. A noter que VS doit être absolument patché avec le SP1 avant d'installer tout ça : Les Silverlight Tools.

Le Toolkit

Silverlight 3 est un produit riche, mais il l'est encore plus lorsque le toolkit est installé. De très nombreux contrôles indispensables sont ajoutés : le Silverlight Toolkit.

Les RIA Services

Grâces aux Services RIA, la gestion de données distantes (n-tiers) devient un jeu d'enfant. C'est un must pour tous ceux qui souhaitent développer des applications orientées données avec Silverlight : .NET RIA Services.

Deep Zoom Composer

Si vous souhaitez créer des images Deep Zoom, il est nécessaire de posséder le Composer : Deep Zoom Composer.

Le site officiel

Encore un lien indispensable ! La partie "getting started" vous renseigne sur les téléchargement de base et propose même un installeur global "Microsoft Web Platform". Vous trouverez aussi sur ce site de nombreuses vidéos de présentation et de formation (en anglais) : Le Site officiel Silverlight.

Dot.Blog

Et oui ! Si vous souhaitez rester à jour et être au courant, le mieux c'est encore de venir sur Dot.Blog le plus souvent possible ou mieux, de s'abonner au flux RSS et surtout : Stay Tuned !

Code source Silverlight 'les codes postaux'

odahan.nospam@nospam.e-naxos.com (Olivier) — Sat, 22 Aug 2009 01:23:00 +0200

Il y a quelques temps j'avais mis en ligne l'application exemple Codes Postaux Français sous Silverlight. Application Silverlight 2.0 montrant l'utilisation d'un service Web avec base de données.

Beaucoup de lecteurs m'ont demandé si le code source était disponible, ce qui n'était pas le cas. J'avais prévu d'écrire un article se basant sur ce code mais le temps passant vite sans pouvoir mener à bien cette écriture j'ai opté pour une publication du code source complet, brut de fonderie.

Vous trouverez le lien de téléchargement sur la page suivante : http://www.e-naxos.com/Blog/page/Exemples-Silverlight.aspx

Silverlight 3 : Un média player complet bien caché !

odahan.nospam@nospam.e-naxos.com (Olivier) — Fri, 21 Aug 2009 00:08:00 +0200

Silverlight 3 est livré de base avec un contrôle très versatile, MediaElement, capable de jouer de nombreux formats comme les mp3 ou les vidéos.

Si ce contrôle est très puissant il est un peu "nu" de base et il faut soi-même ajouter les boutons de commande comme "play" et looker l'ensemble. Avec Expression Blend 3 c'est un jeu d'enfant. Enfin, de grand enfant qui a un peu de temps devant lui tout de même. D'où la question : n'existerait-il pas un MediaElement déjà tout habillé ?

Si vous possédez Expression Media Encoder 3 vous savez que cet extraordinaire outil (servant principalement à encoder des médias) donne le choix entre plusieurs formats de sortie dont des projets HTML tout fait intégrant un média player tout looké, et mieux encore, avec le choix parmi de nombreux modèles.

Quel rapport entre Media Encoder et un projet Blend/VS ? C'est tout simple : lorsque vous installez Media Encoder, sous Blend 3 dans l'onglet Assets vous disposez, en plus de MediaElement d'un nouveau contrôle "MediaPlayer" !

Par défaut ce composant ressemble à l'image ci-dessous. Pour le relooker, il suffit de faire un clic droit et d'éditer un copie du template !

Reste la question à 10 centimes d'euro : oui mais Media Encoder est livré avec de nombreux modèles dont certains ont déjà un look sympa, ne pourrait-on pas récupérer ces modèles au lieu de templater à la main le MediaPlayer ?

Si, c'est possible (© Les Nuls, "Hassan Cehef").

Comment ? Là c'est plus cher... Non, comme je suis un chic type, voici la solution gratuite :

Encoder 3 s'installe avec le code source des modèles qui se trouvent dans le répertoire "C:\Program Files\Microsoft Expression\Encoder 3\Templates\en", il suffit donc de piocher le modèle qu'on désire utiliser, et grâce aux sources d'extraire le contrôle avec son template et de l'intégrer à son propre projet !

Le célèbre Tim Heuer décrit (en englais) la méthode à suivre, je vous renvoie ainsi à son billet Using Encoder Templates in your Silverlight Application si jamais vous n'arrivez pas à vous dépatouiller seul avec le code source des projets Encoder 3.

Intégrer de la vidéo, même HD, dans une application Silverlight n'a jamais été aussi simple... et beau.

Amusez-vous bien, et .. Stay Tuned !

Silverlight 3 : un Behavior ajoutant un effet de reflexion (avec les nouvelles WriteableBitmap)

odahan.nospam@nospam.e-naxos.com (Olivier) — Sat, 08 Aug 2009 03:21:00 +0200

Dans le précédent billet je vous proposais d'écrire un Behavior effectuant une rotation animée d'un élément visuel, aujourd'hui je vous invite à la réflexion...

Je veux parler de l'effet de réflexion tant à la mode. WPF sait parfaitement le faire grâce notamment au brosses visuelles qui permettent facilement de "peindre" un contrôle avec la copie visuelle d'un autre objet (ou arbre d'objets). Hélas, Silverlight 3 ne possède pas encore de brosse de ce type et pour obtenir l'effet désiré il faut dupliquer le ou les objets sources et leur faire subir une rotation, un flip, et l'ajout d'un masque d'opacité. Tout cela est assez fastidieux il faut bien l'avouer.

Mais grâce aux Behaviors il est possible de rendre tout cela automatique et avec l'aide des WritableBitmap il n'est même pas nécessaire de dupliquer tous les objets !

J'ai déjà détaillé dans le billet précédent la technique de création d'un Behavior, je vous renvoie ainsi à cet exemple pour la base. Pour l'effet de réflexion, le mieux est de regarder ci-dessous l'exemple live :

[silverlight:source=/SLSamples/Reflection/ReflectionBehavior.xap;width=424;height=294]

Pour créer cet effet nous allons utiliser une nouvelle classe de Silverlight 3 : les WritableBitmap. Cette classe permet de créer des images de toute pièce ce qui n'était pas possible jusqu'à lors.

Non seulement les WritableBitmap permettent de créer une bitmap par code, mais en plus elle possède une méthode de Render qui est capable de faire le rendu de tout objet ou arbre visuel et de le placer dans la bitmap. Nous allons utiliser cette possibilité pour remplir une bitmap à laquelle nous appliquons ensuite quelques transformations (renversement, échange gauche/droite, translation). Un masque d'opacité est ajouté pour l'impression de dégradé d'opacité.

Le Behavior fonctionne sur des sources de type Canvas uniquement, cela permet d'illustrer comment limiter un Behavior à une classe ou une branche de classes donnée. Une fois l'image du reflet créé elle est ajoutée en tant qu'élément au canvas (après avoir pris soin de supprimer la précédente image s'il y en a déjà une).

Le Behavior n'a pas de rendu en mode design sous Blend 3, c'est un petit défaut. De même l'effet de réflexion est créé une fois pour toute et n'est modifié que si le canvas source voit sa taille changée. Si vous créez dynamiquement des objets sur celui-ci, le reflet ne changera pas. Bien entendu on pourrait penser connecter le Behavior à l'événement de rendu du canvas LayoutUpdated. Cela eut été une solution élégante. Hélas on créerait une boucle infinie puisque notre Behavior ajoute un objet au canvas ce qui déclenche le renouvellement de son rendu. On pourrait améliorer les choses en ne faisant pas le rendu dans le canvas source et en ajoutant une propriété au Behavior qui serait un objet de type Image (non enfant de la source) qu'on utiliserait comme sortie de rendu de l'effet de reflet. Mais cela poserait d'autres problèmes.

Toutes les idées sont envisageables et le code proposé n'est qu'un exemple. A vous de l'améliorer sans oublier de venir ici nous dire ce que vous avez fait !

Côté paramétrage le Behavior permet de modifier les points de départ et d'arrivée du dégradé du masque d'opacité ainsi que l'offset sur l'axe Y. Sans ce dernier le reflet serait collé au canvas source ce qui n'est pas forcément très beau. Par défaut un décalage de 3 pixels vers le bas décolle légèrement le reflet de l'original.

Code la publication d'un code un peu long n'est pas forcément très lisible sur le blog, je vous renvoie au code source du projet complet que vous n'avez plus qu'à télécharger ici : ReflectionBehavior.zip (62,91 kb)

Et Stay Tuned !

Silverlight 3 : Ecrire des Behaviors (composants comportementaux)

odahan.nospam@nospam.e-naxos.com (Olivier) — Fri, 07 Aug 2009 20:44:00 +0200

Blend 3 est une version majeure de ce puissant outil qui permet de travailler le visuel d'une application WPF ou Silverlight. Blend 3 tend vers une plus grande simplicité de manipulation notamment pour les infographistes qui ne veulent / peuvent s'investir dans du code trop complexe.

Les notions de Behaviors (comportements), Actions et Triggers (déclencheurs) sont soient nouvelles pour ce qui est de la première, soit sont renforcées pour les secondes. Le but étant bien de pouvoir ajouter du comportement visuellement sans programmation. Avec les outils d'il y a 15 ans comme VB Microsoft inventait la notion de composant visuel qui se place sur une fiche par Drag Drop. Un bon en avant quand on connaît les méthodes qui ont précédé et quand on sait avec le recul quel succès a eu cette technologie et ses clones (EDI Delphi ou Java...) ! Avec Blend 3 Microsoft innove encore dans une voie qui trace forcément ce que sera l'avenir : le "composant comportemental". On applique le "RAD" (mot plus très en vogue mais qui garde tout son sens) non plus seulement au visuel mais aussi au code.

Aujourd'hui je vais vous parler des Behaviors (comportement).

Qu'est qu'un Behavior ?

Un Behavior est un comportement, c'est à dire un bout de code qui peut faire à peu près n'importe quoi. Avec ça, vous êtes bien avancé allez-vous dire ! Mais imaginez tout ce que peut faire un bout de code autonome (ne dépendant pas d'états externes) et faites un joli paquet cadeau autour afin qu'il apparaisse dans une palette, comme un composant visuel et vous obtenez un Behavior. Un Behavior est donc avant tout une sorte de code snippet qui porte un nom et qui est listé dans Blend comme le sont les composants. Un Behavior n'existe en renvanche pas par lui-même, comme un composant Rectangle ou Button par exemple. Un Behavior s'accroche à un composant existant et c'est en jouant le poisson pilote vis à vis de ce composant qu'il lui amène le fameux comportement.

Un petit exemple pour clarifier : Imaginons qu'on souhaite pouvoir déplacer un objet par Drag Drop, il faudra gérer le mouse Down, le mouse Up et le mouse Move selon un scénario classique que je ne développerai pas. Imaginons maintenant que nous souhaitions apporter le même comportement à un autre objet. Il faudra programmer aussi tous ces événements. Si maintenant nous encapsulons tout cela dans un Behavior, il suffira de déposer le dit Behavior sur tous les composants qui, ipso facto, disposeront du comportement. La réutilisation du code est totale. Côté utilisation de Blend cela permet même de développer une application sans être développeur pour peu qu'on dispose d'une bonne bibliothèque de Behaviors, d'Actions et de Triggers (je reparlerai des deux derniers dans de prochains billets).

Créer un Behavior

Créer un nouveau Behavior est aussi simple que de créer une nouvelle classe dérivant de Behavior<T>. Il faut néanmoins à trouver la classe mère... Elle se cache dans un assembly qui n'est pas référencé de base et qui joue un peu à cache-cache... Avec la finale de Blend 3 il s'agit de :

C:\Program Files\Microsoft SDKs\Expression\Blend 3\Interactivity\Libraries\Silverlight\System.Windows.Interactivity.dll

Une fois la classe créée, il ne reste plus qu'à surcharger deux méthodes : OnAttached() et OnDetaching(). C'est à partir de là qu'on peut programmer le comportement. Le Behavior peut connaître l'objet auquel il est attaché : AssociatedObject.

Un Behavior Exemple : RotateBehavior

Pour illustrer le propos j'ai cherché quel genre de petit Behavior je pourrais bien développer. Les classiques du genre ne me disait rien (faire en flou quand la souris entre sur l'objet, ou bien changer sa transparence, etc). Mais, restons réalistes, pour un petit exemple on ne pouvait faire beaucoup plus compliqué. Je me suis donc dit, tiens, une transformation du type rotation, je n'ai pas encore vu, et mieux, avec une animation pour tout de même pimenter la chose...

[silverlight:source=/SLSamples/Behavior/Behavior_base.xap;width=460;height=210]

Dans l'arbre des objets on peut voir le RotateBehavior accroché aux rectangles et à l'objet texte :

De même, pour le behavior sélectionné on peut voir les propriétés suivantes :

On note la propriété Angle, en degrés, et la propriété Duration qui définit la longueur de l'animation. Bien entendu, chaque RotateBehavior placé sur chacun des objets est paramétrable de façon séparée.

Le code exemple

Le blog est parfait pour publier des extraits de code mais pas des listing entiers. Du coup, plutôt que de vous imposer une lecture difficile, je vous propose de télécharger le projet exemple à ouvrir sous Blend 3 ou Visual Studio 2008 + SL3 SDK: Behavior_base.zip (61,84 kb)

Amusez-vous bien avec les comportements, et Stay Tuned !

De la 3D Gratuite ! ... Mais limitée dans le temps...

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 05 Aug 2009 23:51:00 +0200

Dans mon dernier billet je vous parlais de TrueSpace de Caligary qui suite au rachat par Microsoft avait rendu le téléchargement gratuit du logiciel et des vidéos de formation.

Hélas, durant l'année écoulée Microsoft a aussi été affecté par la crise américaine puis mondiale et il a fallu faire des coupes sombres... TrueSpace, en tout cas la société Caligary fraichement acquise, font partie de la charette...

Du coup le logiciel et les vidéos sont toujours téléchargeables mais on ne sait pas pour combien de temps. Le fondateur de Caligary explique dans une lettre qu'il est préférable de tout télécharger et de garder ça sur un disque dur car le site Web pourrait ne plus être dispo dans un délai non précisé.

Cela n'enlève rien à la qualité et à l'aubaine que représente TrueSpace gratuit, un soft à 600 dollars plutôt bien fait. Mais en revanche, dépéchez vous de télécharger !

Pour info, TrueSpace sait importer depuis de nombreux formats dont 3DS et sait exporter aussi vers 3DS (et d'autres). Ses possibilités graphiques et d'animation sont vraiment très bonnes et si vous prenez en compte que ZAM3D et Swift3D d'Electric Rain (dont j'ai déjà parlé ici) accèptent en importation le format 3DS vous comprendrez l'intérêt qu'il peut y avoir à posséder un soft de 3D gratuit pour concevoir des objets ou des scènes complètes qui peuvent ainsi être migrées vers WPF ... La chaîne graphique devenant : TrueSpace -> Swift3D / Zam3D -> WPF.

Faites vite, c'est une superbe affaire...

De la 3D Gratuite !

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 05 Aug 2009 20:08:00 +0200

En 2008 Microsoft a racheté la société Caligary, principalement parce que cet éditeur dispose d'outils 3D qui, on peut se douter, pourraient s'avérer utile pour le développement de jeux XBox ou d'objets 3D pour XAML. Cette annonce est passée un peu sous silence, et pourtant... Désormais les produits de Caligary sont disponibles gratuitement ! Notamment TrueSpace, un outil de modélisation et d'animation 3D proche d'un LiteWave ou d'un Maya (proche, pas forcément équivalent, juste pour vous faire une idée du type d'outil).

Téléchargez dès maintenant TrueSpace et éclatez-vous en 3D, surtout que le site de Caligary fournit des videos de formation pour se mettre le pied à l'étrier.

Bonne 3D !

(et dois je rajouter : Stay Tuned !)

Prendre les bonnes mesures (à l'écran) ! [Rooler un utilitaire sympa]

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 05 Aug 2009 19:24:00 +0200

Je sais, la rentrée approche et c'est le moment de prendre de bonnes résolutions, mais je ne vais pas jouer les père-la-morale, je vais vous parler de résolution d'écran et de bonnes mesures dont l'unité s'exprime en pixels et non en distance vous séparant du salut de votre âme.

Rooler est un petit utilitaire très sympathique qui offre une barre d'outils permettant de mesurer les objets à l'écran : zones rectangulaires, espace horizontal et vertical entre deux objets visuels.

Simple, efficace et surtout malin car l'outil interprète l'écran comme une image et les distances mesurées le sont entre des pixels et non des objets Windows. Il y a d'ailleurs un réglage de tolérance (un peu comme sous PaintShop ou PhotoShop dans certaines commandes) qui permet d'ajuster le niveau de détection.

Bien pratique et tout petit, à posséder dans sa boîte à outils donc !

Le site avec toutes les explications et le téléchargement du setup : Rooler.

Roulez petits bolides, mais Stay Tuned !

WPF : Qui l'utilise ?

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 05 Aug 2009 18:30:00 +0200

Après plusieurs années de présence et de maturation, WPF a plus que largement prouvé sa capacité à produire des applications riches et esthétiques. Et si la supériorité technique de WPF sur les Windows Forms ou apparentés est une évidence, une question revient très souvent : Mais qui utilise WPF ?

En effet, les applications développées en WPF sont, il faut l'avouer, plus rares que celles en Windows Forms. J'ai de longue date milité pour que cet état de fait change, et je continuerai à la faire (voir par exemple mon article sur les 10 bonnes raisons de préférer WPF et 9 raisons de plus d'utiliser WPF!). Mais ne s'est il vraiment rien passé ? Heureusement non !

Il est vrai que les interfaces séduisantes de WPF vont un peu de pair avec le nouveau look de Windows Vista. Hélas cette mouture de l'OS n'a pas rencontré le succès et la partie a été remise. En fin d'année Windows 7 viendra malgré tout enfoncer le clou. Et là, comme je vous le clame depuis longtemps, il sera juste un peu tard pour vous y mettre, WPF c'est beau, c'est puissant, mais on ne l'apprend pas un matin pour commencer un nouveau projet l'après midi... Ce n'est pas juste une nouvelle librairie d'affichage. Les principes de fonctionnement, les outils (comme Blend), tout est radicalement différent et demande une phase d'apprentissage qui ne peut être niée ni balayée d'un haussement d'épaule. Et je peux vous assurer que les projets que vous commencez aujourd'hui en Windows Forms et que vous testez joyeusement sur votre Windows XP, lorsqu'ils arriveront entre les mains de vos utilisateurs sous Windows 7 l'année prochaine (ou dans 2 ans, vous ne développez pas des softs-kleenex non ?) tous vos softs Winfows Forms auront le même air dinosauresque et désuet qu'une application console...

Bref mettez vous à WPF. Si vous préférez, formez vous en partant de Silverlight. Les bases sont les mêmes et il est vrai que Silverlight a un côté plus "exitant" pour certaines personnes (moi par exemple!). Mais l'un ou l'autre, il est temps de mettre les bouchées doubles !

Microsoft a sorti une petite brochure qui montre les principales applications WPF qui sont ou qui font sortir. De Intel à AMD, de BMW à AutoCad, regardez le look des applis que vos utilisateurs auront sur leur bureau juste à côté des vôtres en Windows Forms... Prenez du recul et, sincèrement, tiendrez-vous la comparaison ? ... Je ne le crois pas.

Voici quelques liens pour bien commencer :

Ce ne sont que quelques points de départ, il y en a bien d'autres dans mes billets mais vous les avez déjà trouvés si vous êtes un lecteur fidèle...

Bonne lecture, et Stay Tuned !

Silverlight 3 et DeepZoom

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 05 Aug 2009 06:56:00 +0200

Deep Zoom, vous connaissez ? Probablement, c'est tellement sympa ! Si vous ne savez pas ce que c'est, voici en deux mots quelques explications : Deep Zoom est une technologie permettant d'afficher des images énormes sans avoir besoin d'attendre que tout soit téléchargé. On peut ainsi faire un "zoom profond" (deep zoom) sur une image, ou plus amusant, sur une composition d'images. Si vous connaissez Binq Maps, cela vous donne une bonne idée (partir d'une vision de la france depuis le ciel et zoomer jusqu'à voir le nombre de voitures garées devant chez vous).

Des tas de possibilités s'ouvrent si je vous dis que le logiciel Deep Zoom Composer est gratuit et qu'il permet de créer toute sorte de compositions et qu'il est même capable de créer des exécutables directement utilisables, voire même les sources complètes d'un projet Blend 3 !

C'est à partir de cette dernière option que j'ai créé la démo ci-dessous. Sur la base du projet créé par Deep Zoom Composer j'ai pu modifier certains comportements, améliorer certaines petites choses (notamment à l'aide de Behaviors dont certains sont déjà dans le projet). Vraiment incroyable et d'une rapidité fulgurante, si on fait abstraction du processus de création des milliers de fichiers nécessaires rien que pour la présente démo. En tout 4593 fichiers, 303 sous répertoires pour un poids total de 52,2 Mo. Du lourd donc. Surtout comparé au fichier exécutable Silverlight produit (le .xap) qui ne fait que 79 Ko.

Alors attention aux compositions géantes qu'on est tenté de concevoir, après il faut assumer niveau hébergement !

En revanche les possibilités d'interactions et de personnalisations au travers de Blend 3 sous Silverlight 3 sont innombrables. On sent un potentiel énorme, les idées d'utilisation un peu originales viendront certainement avec le temps une fois familiarisé avec la techno.

Ce billet ne présente pas de code, il suffit de disposer de Deep Zoom Composer, de quelques photos, de suivre la procédure et de bricoler un peu le C# du projet pour obtenir le même résultat. Le but est avant tout de vous parler de Deep Zoom, de vous dire que c'est vraiment fun, et qu'il ne vous reste plus qu'à l'essayer pour l'adopter !

nota: les photos font partie de celles que j'ai prise à Barcelone lors des TechDays 2008. Vous pourrez découvrir une photo d'une fière assemblée, en train de festoyer, et y reconnaître, parmi les autres participants de marque, notre Mitsu national, grand maître de ce genre de réunions gourmandes :-) Ne me cherchez pas sur la photo, il fallait bien quelqu'un pour immortaliser l'instant et tenir l'appareil photo...

Pour jouer avec l'exemple ci-dessus, faites du drag'drop pour déplacer le bloc de photos, cliquez pour zoomer ou utilisez les boutons en bas à droite (visibles quand la souris entre dans l'espace Deep Zoom), notamment le dernier à droite pour passer en full screen.

[silverlight:source=/SLSamples/DeepZoom/DeepZoomProject.xap;width=579;height=292]

Pour d'autres news vous connaissez le refrain : Stay Tuned !

WPF et Silverlight : composants orientés données dans les Toolkits

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 05 Aug 2009 04:33:00 +0200

Trouver des ressources sur les technologies ou outils récents est toujours difficile. Par force, et c'est une Lapalissade, ce qui est plus connu est plus facile à connaître, et vice versa...

Le WPF Toolkit ainsi que Silverlight Toolkit sont des mines de composants ayant beaucoup de choses en commun : même base de code, évolutions rapides et donc releases fréquentes avec à chaque fois des ajouts d'importance. Suivre le ryhtme pourrait réclamer un job fulltime...

Voici un post de Delay's Blog qui résume les dernières ressources autour de la visualisation des données dans ces deux Toolkit : http://blogs.msdn.com/delay/archive/2009/07/19/my-new-home-page-enhanced-updated-collection-of-great-silverlight-wpf-data-visualization-resources.aspx .

Visualiser les données est essentiel à toute application de type gestion, et l'avalanche de nouveautés dans les Toolkits ciblant ce besoin permet désormais d'envisager sérieusement de créer de "vraies" application avec WPF et Silverlight. Par "vraies" j'entends des applications telles que nous en concevons tous régulièrement, et non des petits jeux ou des caroussels tournoyants qui font de magnifiques démos ou des sites Web publicitaires mais qui ne sont pas forcément des applications représentatives du travail habituel d'un développeur. Il est donc d'autant plus important de connaître ces extensions de WPF et de Silverlight et pour ce faire il faut trouver les bonnes explications...

A lire absolument donc, pour y piocher des articles, des astuces, ou de simples explications sur toute la partie affichage des données sous Silverlight ou WPF.

Avec ça, vous pouvez vous occuper jusqu'à la rentrée de septembre !

Mais Stay Tuned, car j'ai plein d'autres choses à vous dire d'ici là !

Créer un arbre des répertoires avec XML (et l'interroger avec LINQ to XML)

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 04 Aug 2009 23:21:00 +0200

Pour les besoins d'un prochain billet je voulais obtenir une structure arborescente de test sous la forme d'un fichier XML. Une telle chose peut se faire à la main mais cela est fastidieux et à force de copier/coller les données seront trop semblables et donc peu utilisables pour des tests et du debug, ce qui est dommage puisque tel était le but recherché...

Pour générer des données aléatoires mais réalistes je possède déjà un outil fantastique (puisque c'est moi qui l'est fait :-) ), DataGen, un logiciel puissant mais qui n'est pas étudié pour générer des données dont la strucuture est récursive. Restait donc à concevoir un utilitaire pour satisfaire mon besoin de l'instant.

Je n'aime pas développer "pour rien" donc il fallait que cet utilitaire en soit bien un. Tout disque dur de développeur contient une telle quantité de données que l'ensemble des répertoires forment une superbe structure arborescente ni trop petite ni trop gigantesque. Exactement ce qu'il faut pour des tests ! Ainsi, l'outil devra fabriquer un fichier XML à partir de n'importe quel niveau de répertoire, la structure étant hiérarchique.

Je m'empresse donc de vous faire partager ce petit bout de code qui vous sera utile un jour ou l'autre je pense.

using System;

using System.IO;

using System.Linq;

using System.Xml.Linq;

namespace Enaxos.Tools.Xml

    /// <summary>

    /// This class can generate an XML file from a folder hierarchy.

    /// </summary>

    public static class DirToXml

        /// <summary>

        /// Builds the tree document.

        /// </summary>

        /// <param name="dirname">The name of the starting folder.</param>

        /// <returns>a LINQ to XML <c>XDocument</c></returns>

        public static XDocument BuildTreeDocument(string dirname)

            return new XDocument(new XDeclaration("1.0", "utf-8", "yes"),

                new XComment("Structure au "+DateTime.Now),new XElement("directories", BuildTree(dirname)));

        /// <summary>

        /// Builds the tree (recursive method).

        /// </summary>

        /// <param name="dirName">Name of the starting folder.</param>

        /// <returns>a LINQ to XML <c>XElement</c> being the root (or 1st item) of the tree.</returns>

        public static XElement BuildTree(string dirName)

            var di = new DirectoryInfo(dirName);

            var files = di.GetFiles();

            var dirsize = 0l;

            foreach (var file in files)

                dirsize += file.Length;

            var subdirs = di.GetDirectories();

            // each item is a "directory" having 5 attributes

            // name is the name of the folder

            // fullpath is the full path including the name of the folder

            // size is the size of all files in the folder (in bytes)

            // files is the number of files in the folder

            // subdirs is the count of possible sub directories in the folder

            var elem = new XElement("directory",

                new XAttribute("name", di.Name),

                new XAttribute("fullpath",dirName),

                new XAttribute("size", dirsize),

                new XAttribute("files",files.Count()),

                new XAttribute("subdirs",subdirs.Count()));

            foreach (var dinf in subdirs)

                var elemDir = BuildTree(dirName + "\\" + dinf.Name);

                elem.Add(elemDir);

            return elem;

Ce code peut être utilisé sans passer par un fichier disque puisqu'on récupère le document en mémoire. L'exemple ci-dessous montre comment appeler le code et comment interroger la structure via Linq To Xml pour connaître les répertoires vides (n'ayant ni fichier ni sous répertoire) :

   1:  var d = DirToXml.BuildTreeDocument(@"D:\WpfToolkit");

   2:  d.Save(@"d:\test.xml");

   3:  Console.WriteLine(d.ToString());

   4:  Console.WriteLine(new string('-',60));

5:

   6:  var q = from e in d.Descendants("directory")

   7:          where (int) e.Attribute("files") == 0

   8:               && (int)e.Attribute("subdirs") == 0

   9:               orderby (string) e.Attribute("fullpath")

  10:               select e.Attribute("fullpath");

11:

  12:  Console.WriteLine("Répertoires vides");

  13:  foreach (var element in q)

  14:    { Console.WriteLine(element); }

  15:  Console.WriteLine(string.Format("{0} répertoires vides",q.Count()));

A bientôt pour un prochain billet, so.. Stay Tuned !

Silverlight 3: Accélération GPU et cache image

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 04 Aug 2009 18:39:00 +0200

Dans un récent billet sur les Pixel Shaders (effets bitmap) j'avais, par un raccourci de pensée un peu rapide, associé trop facilement les capacités d'accélération graphique GPU de Silverlight 3 avec celles de WPF. Or il existe des nuances très sensibles entre les deux implémentations.

Par souci de rigueur j'ai modifié le billet original en lui ajoutant les précisions nécessaires mais les corrections de billets ne sont pas propagées par feedburner qui gère une parite des flux RSS des abonnés à mon blog. Et pire, ceux qui ont déjà téléchargé le billet sous Outlook ou un autre news reader n'ont aucune chance de voir la correction. Ne reste plus qu'à créer un nouveau billet pour m'assurer que l'info est passée.. Voici la notice ajoutée au billet cité plus haut :

--extrait--

Quelques mots sur l'accélération GPU : Même si ce n'est pas le sujet du présent billet, il s'agit d'une nouvelle feature très intéressante de SL3. On a tendance hélas (et j'ai été le premier à me faire "avoir") à trop vite faire le parallèle avec WPF et à transposer ce que fait l'accélération sous ce dernier. En fait, le support de l'accélération GPU de SL3 est pour l'instant assez limité et ne se met en route que de façon volontaire. Elle ne s'applique pas aux effets bitmaps ni aux nouveaux flux vidéos qui restent traités par le CPU.

Malgré tout le système d'accélération graphique peut rendre d'immense service, dans certains de mes tests sur l'animation d'images assez grandes j'ai pu voir mon PC passer de 88% d'utilisation CPU (double coeur Asus plutôt rapide) à moins de 4% ! Ce qui est énorme. Mais pour profiter de l'accélération il faut aboslument en connaître le fonctionnement et les limitations.

Je vous invite ainsi à lire l'excellent billet de Andras Verlvart sur la question. Il est assorti d'une application exemple en live qui permet de bien voir l'effet des différentes possibilités d'accélération et leur impact sur le CPU et le GPU. Cet article est en anglais, pour ceux qui préfère la lecture en français, David Rousset a écrit un billet qui fait le point sur cette même question.

--fin d'extrait--

Espérant ainsi avoir rétabli la précision technique nécessaire à propos de cette nouvelle possibilité de Silverlight 3, et incidemment, vous avoir donné envie de vous familiariser avec et de l'adopter dans vos développements,

Stay Tuned pour d'autres nouvelles !

« Il neige » ou les boucles d’animation, les fps et les sprites sous Silverlight

odahan.nospam@nospam.e-naxos.com (Olivier) — Mon, 03 Aug 2009 01:58:00 +0200

Il n’est jamais trop tard pour préparer Noël et la période estivale est le meilleur moment pour parler de neige, vision rafraîchissante s’il en est. Mais tel n’est pas réellement mon propos. Sous ce prétexte glacé (mais pas glaçant) se cache des notions techniques très utiles sous Silverlight (ou WPF).

Les boucles d’animation, le contrôle des fps (frame per second, images par seconde) et les sprites (petits objets autonomes animés) sont certes autant d’incursions dans le monde du jeu mais la créativité permet d’envisager mille utilisations de ces techniques dans d’autres contextes.
Je me suis librement inspiré d’un billet s’intitulant « Making it snow in Silverlight » écrit par Mike … Snow (facile à se souvenir !). J’utilise un code différent et (à mon sens) amélioré, mais il était important de rendre à Snow la neige qui lui appartient (et de faire un peu d’humour bas de gamme au passage).

Avant d’expliquer certains aspects, voici une démonstration live que vous pouvez passer en mode plein écran :

[silverlight:source=/SLSamples/IlNeige/IlNeige.xap;width=500;height=350]

Le but

Le but du jeu est donc de faire tomber de la neige sur un fond, c'est-à-dire de faire se mouvoir des centaines d’objets autonomes ayant chacun un aspect légèrement différent et une trajectoire un peu aléatoire. Le tout assez vite pour que cela paraisse naturel.

Le principe

Chaque flocon de neige est en réalité une instance d’un UserControl, il y a ainsi des centaines d’instances au même instant. Chaque flocon est responsable de son affichage et de la façon dont il avance à chaque « pas ». La coordination générale étant réalisée par une boucle d’animation principale, c’est elle qui scande le rythme et demande à chaque flocon d’avancer d’un « pas ».
Tout se trouve donc dans deux endroits stratégiques : la boucle principale et le UserControl « Flocon ».

Suivre l'article : le code n'étant pas très lisible dans le blog, sauf extraits très courts, je n'ai volontairement pas placé ce dernier dans le corps du billet. Je vous conseille ainsi de télécharger le projet (en fin de billet) et de suivre les explications en ayant le code chargé sous Blend 3 ou Visual Studio (2008 + SL3 minimum).

Le sprite Flocon

Il s’agit d’un UserControl possédant une interface très simple puisqu’il s’agit d’un bitmap en forme d’étoile (ou pourrait utiliser n’importe quelle forme vectorielle créée sous Design ou Illustrator). Côté XAML on retrouve ainsi une grille avec un PNG à l’intérieur, rien de palpitant. A noter qu’au niveau du UserControl lui-même on définit deux transformations : une d’échelle (FlakeScale) et une de rotation (FlakeRotation). Dans l’exemple de la neige cette dernière n’a que peu d’effet visuel sauf lorsqu’on choisit une taille assez grosse pour les flocons. L’œil ne discerne pas forcément la rotation de façon consciente mais comme elle est choisit aléatoirement pour chaque flocon cela renforce l’aspect global plus « organique ». De plus il s’agit d’illustrer des techniques utilisables dans d’autres contextes ou avec d’autres sprites pour lesquels l’effet serait plus évident. La technique est extrapolable à toutes les transformations supportées, même les nouvelles transformations 2,5D de Silverlight 3.
Le code de la classe Flocon se divise en deux points : le constructeur et la méthode « Tombe ».

Le constructeur

Il est responsable de la création de chaque instance. C’est à ce niveau qu’on introduit un peu d’aléatoire dans la rotation du flocon. On choisit aussi à ce moment la position de départ en X (la position en Y étant toujours à zéro au départ).
La gestion des flocons est séquentielle (par la boucle d’animation que nous verrons plus loin). De fait il n’y a pas de multithreading et on peut se permettre un développement très simple de la classe. Par exemple les limites du tableau de jeu sont stockées dans des propriétés statiques de la classe. Le programme initialise ces valeurs au lancement et les modifie à chaque fois que la taille du tableau est changée (redimensionnement du browser).
Le constructeur fixe aussi de façon aléatoire l’échelle de l’instance afin que chaque flocon soit de taille légèrement différente par rapport à une échelle de base. Cela permet d’obtenir un effet de profondeur de champ.

La méthode « Tombe »

Il s’agit bien de tomber et non d’outre-tombe et de zombies façon Thriller du très médiatisé Jackson. Pour chaque flocon il s’agit donc ici de savoir choir, avec si possible le sens du rythme et du mouvement du sus-cité Michael.
Pour ce faire la méthode « Tombe » doit calculer la nouvelle position X,Y du flocon. Les flocons évoluent dans un espace de type Canvas particulièrement indiqué pour tout ce qui doit être positionné de cette façon à l’écran.
Sur l’axe des Y le déplacement s’effectue d’un pixel à la fois. Une incrémentation simple est utilisée. Sur l’axe horizontale le flocon change régulièrement de direction pour rendre l’ensemble visuel plus réaliste. On utilise ici un tirage aléatoire pour savoir s’il faut ou non changer de direction. Dans l’affirmative on modifie la valeur du pas de déplacement (hzDeplacement). La position sur X est alors calculée en ajoutant cette valeur à la position courante.
Reste à savoir quand un flocon n’a plus d’intérêt, c'est-à-dire lorsqu’il échappe au champ de vision et qu’il peut être détruit (n’oublions pas que des centaines d’instances sont gérées à la fois et que tout flocon inutile doit être détruit le plus vite possible pour d’évidentes raison d’efficacité). C’est le rôle du test en fin de méthode qui initialise la valeur « HorsZone ». Lorsqu’elle passe à true, le flocon peut être détruit. Cette information est utilisée par la boucle principale.

La boucle d’animation

Maintenant que nous disposons d’un modèle de flocon (la classe Flocon) reste à animer de nombreuses instances pour donner l’illusion de la neige qui tombe.
La technique pourrait utiliser un Timer ou bien une StoryBoard vide dont le déclenchement est réalisé à chaque pas (et comme elle s’arrête immédiatement on obtient une sorte de Timer rythmant la boucle principale). Cette dernière façon de faire était très utilisée sous Silverlight 1.x. Selon la vitesse de la machine cliente la boucle est ainsi déclenchée plus ou moins vite ce qui évite le problème de fixer un pas déterminé comme avec un Timer. Toutefois il est en réalité inutile de calculer la position des flocons plus rapidement que les FPS, pure perte d’énergie, ni de calculer moins souvent (autant abaisser les FPS).

Sous Silverlight 2 un événement a été ajouté donnant accès au rythme du moteur de rendu : CompositionTarget.Rendering. En gérant la boucle principale dans ce dernier on s’assure d’être parfaitement dans le tempo du moteur de rendu, ni plus rapide, ni plus lent.

Cette technique a toutefois dans le principe un défaut connu dans tous les jeux programmés de la sorte : la célérité de l’ensemble dépend de la vitesse de la machine hôte. Un PC très lent fera donc tomber la neige trop lentement, alors qu’un PC fulgurant des années 2020 ne permettra même plus de distinguer le déplacement des flocons tellement cela sera rapide, rendant le jeu « injouable ». Pour le premier problème il n’y a pas vraiment de solution, on ne peut donner plus puissance à la machine hôte (sauf à permettre à l’utilisateur de diminuer la charge du jeu lui-même en limitant par exemple le nombre maximum de flocons, le paramètre de densité peut jouer ce rôle dans notre exemple). Quant au second problème il trouve sa réponde dans la limite à 60 FPS par défaut de Silverlight, limite modifiable via les paramètres du plugin (voir ce billet).

Débarrassés des écueils propres à cette technique, l’événement de rendering devient l’endroit privilégié pour placer le code d’une boucle principale d’animation.

Le contrôle des FPS

Lorsque vous exécutez une application de ce type il est important de contrôler les FPS pour voir comment certaines améliorations du code peuvent accélérer ou non le rendu. Pour ce faire Silverlight permet d’activer l’affichage de deux informations essentielles dans la barre d’état du browser : les FPS actuels et la limite fixée dans le plugin. L’activation se fait via Application.Current.Host.Settings en plaçant EnableFrameRateCounter à true. Il est bien entendu vivement conseillé de déconnecter la fonction en mode Release. Si votre navigateur et ses réglages le supporte vous devez en ce moment pouvoir lire ces informations en bas à gauche de la barre d'état (et si l'exemple live de l'application en début de billet s'est chargé correctement).

Attention : Selon les réglages de sécurité Internet Explorer autant que FirexFox peuvent ne pas autoriser la modification de la barre d’état. Sous IE (sous FF cela est quasi identique) il faut vérifier le paramètre Outils / Options Internet / Sécurité / Zone Internet / Personnaliser le niveau / Autoriser les mises à jour à la barre d’état via le script. Ce paramètre doit être activé pour voir les FPS.

Le Rendering

A chaque pas du rendering nous allons réaliser deux tâches essentielles : déplacer les flocons déjà présents et supprimer ceux devenus inutiles et créer de nouveaux flocons.
Pour déplacer les flocons nous ne faisons que balayer la liste de tous les flocons et appeler la méthode « Tombe() » de chacun. Au passage nous archivons dans une liste temporaire tous les flocons dont l’état HorsZone est passé à true. En fin d’animation les flocons inutiles sont supprimés de la liste principale les laissant ainsi disponible au Garbage Collector.

Pour créer de nouveaux flocons nous déterminons si la densité désirée est atteinte ou non. Le processus est randomisé pour plus de réalisme bien que le seuil de densité soit lui fixé par le programme (et modifiable dans notre exemple). Comme le placement de chaque flocon est réalisé dans le constructeur de la classe Flocon il n’y a rien d’autre à faire que de créer les flocons et de les ajouter à la collection Children du Canvas parent.

Le plein écran

Silverlight permet de passer une application en mode plein écran. Sachez toutefois que ce mode pose de sérieuses conditions à son utilisation. Notamment il ne peut être activé qu’en réponse directe à un clic de l’utilisateur. Cela permet d’éviter (en partie) qu’une application Silverlight soit utilisée de façon à tromper l’utilisateur final en prenant le contrôle de tout l’écran sans son autorisation (on pourrait penser à un fake du bureau Windows permettant par exemple d’extorquer un login). De même, lorsque l’application bascule en mode plein écran un message impossible à supprimer est affiché pour avertir l’utilisateur et lui indiquer que l’appui sur Escape permet de sortir de ce mode spécial.

Si cela n’était pas suffisant, les saisies clavier sont impossibles en plein écran. Seules certaines touches ont un effet (voir la documentation sur MSDN). Ne pensez pas utiliser le plein écran pour une application de saisie par exemple. En revanche pour visionner des vidéos ou pour créer un jeu les touches disponibles et la gestion de la souris sont suffisants. C'est le cas de notre démo.

Une fois connues ces limites raisonnables (Microsoft ne veut pas, à juste titre, que Silverlight soit utilisé par des fraudeurs et autres adaptes du phishing) le passage en plein écran s’effectue par Application.Current.Host.Content.IsFullScreen en mettant cette propriété à true, et ce en réponse au clic sur un bouton en général.

Le code

Télécharger le projet complet de l'exemple "IlNeige" : IlNeige.zip (229,54 kb)

Silverlight : Dessiner des horloges, un peu de trigonométrie !

odahan.nospam@nospam.e-naxos.com (Olivier) — Sat, 01 Aug 2009 20:17:00 +0200

Tout le monde sait faire un cercle, enfin une Ellipse particulière sous Silverlight ayant une hauteur et une largeur identiques. En revanche placer les marques des minutes ou placer correctement le texte des heures dans le cadran n'est pas toujours évident.

Si on tente de le faire "à la main", et même sous Blend, c'est une véritable galère (imaginez 60 petites ellipses pour les secondes à répartir soigneusement, sans parler d'un éventuel changement de dimension qui mettrait tout par terre !).

La seule solution raisonnable passe ici forcément par code. Mais malgré la croyance populaire tous les informaticiens ne sont pas forcément des "bêtes" en math ! On peut être un expert en SQL sans se rappeler ses cours de trigonométrie et on peut développer toute une architecture multithreadée sans même savoir ce qu'est un Groupe de Lie. Mais parfois ce genre de connaissance peut manquer notamment dès qu'on aborde le traitement d'image ou de dessin.

[silverlight:source=/SLSamples/ClockHours/ClockHours.xap;width=360;height=222]

Le but du jeu est donc ici de répartir harmonieusement des objets sur un cercle. Dans un cas il s'agit de texte (les heures) dans l'autre des cercles (les dots). Mais avant de regarder le code, rappelons quelques points mathématiques :

L'unité Math fonctionne en radians c'est à dire qu'un cercle vaut 2 Pi (donc deux fois 3.1415926...). C'est bête parce qu'en général un humain normalement consituté raisonne plutôt en degrés, ce qui est plus facile à se représenter mentalement.

(vous pouvez copier l'original en svg ici)

Comme on peut le remarquer en radian le 0 se trouve au milieu à droite du cercle et non pas en haut à midi comme on pourrait s'y attendre. Du coup, comme les fonctions mathématiques de .NET marchent en radians si on raisonne en degrés il faudra penser à cette petite spécifité lors de la conversion. Par exemple, la place de "1 heure" sur une horloge se situe à 300 degrés et non pas à 30° (1 pas de 360 divisé par 12).

Le code ci-dessous permet d'écrire les heures dans l'exemple live Silverlight plus haut dans ce billet :

private void writeHours(int radius, int offsetx, int offsety, Canvas parent, double fontsize, Color color)

            var h = 1;

            for (var angle=300;angle<=630;angle+=30)

                var t = new TextBlock {

                        Foreground=new SolidColorBrush(color),

                        Text=h.ToString(),

                        FontSize = fontsize};

                h++;

                t.SetValue(Canvas.LeftProperty,(radius * Math.Cos(DegreetoRadian(angle))) + offsetx);

                t.SetValue(Canvas.TopProperty,(radius * Math.Sin(DegreetoRadian(angle))) + offsety);

                parent.Children.Add(t);

Les paramètres sont les suivants :

radius : rayon du cercle virtuel sur lequel les heures sont posées
offsetx et offsety : positionnement du centre du cercle dans le canvas parent, sachant que le 0,0 se trouve en haut à gauche.
parent : le Canvas parent
fontSize : taille de la fonte
color : la couleur de la fonte

Pour dessiner les dots on utilise le même principe (sans s'encombrer des détails du point de départ décalé puisque toutes les dots sont identiques).

Le code n'est pas optimal et on peut certainement faire mieux, mais cela vous donne un point de départ ... Pour compléter le tout, vous pouvez télécharger le projet : ClockHours.zip (61,42 kb)

Stay Tuned !

Silverlight 3 : Gestion des cookies

odahan.nospam@nospam.e-naxos.com (Olivier) — Fri, 31 Jul 2009 22:26:00 +0200

Silverlight propose un espace de stockage privé pour chaque application sur la machine cliente. Cet espace s'appelle l'Isolated Storage (stockage isolé, car protégé et isolé du reste de la machine cliente). C'est dans cet espace qu'il est conseillé de sauvegarder les données propres à l'application (j'y reviendrai dans un prochain billet). Toutefois on peut amené pour certaines informations à préférer le stockage sous la forme de Cookies traditionnels. On peut aussi avoir besoin de lire certains cookies posés par l'éventuelle application hôte en ASP.NET par exemple.

Quelles que soient les raisons, il peut donc s'avérer utile de manipuler les cookies depuis une application Silverlight.

L'application exemple ci-dessous vous permet de tester en live cette fonctionnalité :

[silverlight:source=/SLSamples/Cookies/Cookies.xap;width=380;height=322]

Techniquement, et après avoir ajouté à votre code le using du namespace "System.Windows.Browser", il suffit pour créer (ou modifier) un cookie d'appeler la méthode SetProperty de HtmlPage.Document :

   1:  private bool setCookie(string key, string value)

   2:          {

   3:              if (string.IsNullOrEmpty(key) || string.IsNullOrEmpty(value))

   4:              { return false; }

   5:              DateTime dt = calExpiry.SelectedDate ?? DateTime.Now

   6:                  + new TimeSpan(1, 0, 0);

   7:              string s = key.Trim() + "=" + value.Trim()

   8:                  + ";expires=" + dt.ToString("R");

   9:              HtmlPage.Document.SetProperty("cookie", s);

  10:              return true;

  11:          }

Pour la lecture on accède à la chaîne "Cookies" de HtmlPage.Document qu'on peut ensuite traiter pour séparer chaque cookie :

   1:  private string getCookie(string key)

   2:          {

   3:              string[] cookies = HtmlPage.Document.Cookies.Split(';');

   4:              foreach (string cookie in cookies)

   5:              {

   6:                  string[] pair = cookie.Split('=');

   7:                  if (pair.Length == 2)

   8:                  {

   9:                      if (pair[0].ToString() == key)

  10:                          return pair[1];

  11:                  }

  12:              }

  13:              return null;

  14:          }

Bref, rien de bien compliqué mais qui pourra vous servir dans certains cas.

Le code source du projet (Blend 3 de préférence, sinon VS 2008 + SL3) : Cookies.zip (62,65 kb)

Stay Tuned !

Silverlight 3 (+WPF) : Hatching Effect gratuit + Sources

odahan.nospam@nospam.e-naxos.com (Olivier) — Wed, 29 Jul 2009 22:08:00 +0200

Les pixel shaders de Silverlight 3 fournis "out of the box" ne sont que deux : le drop shadow et le blur. Mais comme cela était prévisible de nombreux programmeurs exercent leur talent en créant de nouveaux effets...

Forcément l'équipe Microsoft de la suite Expression est très bien placée pour ce genre d'exercice et elle nous propose via son blog un effet de crayonnage assez bien fait. Le tout avec install pour automatiquement voir l'effet dans les palettes de Blend 3 mais aussi avec le code source pour l'étudier et faire ses propres effets.

Le mieux est de vous rendre directement sur le blog de l'équipe Expression, et plus particulièrement sur le billet présentant le Hatching effect. Source et install sont téléchargeables depuis le billet.

A noter, l'effet fonctionne aussi avec WPF selon ce qui est dit mais je n'ai testé que sous Silverlight.

Stay Tuned !

Suite Expression 3 finale disponible !

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 28 Jul 2009 03:43:00 +0200

La suite Expression 3 contenant notamment l'extraordinaire Blend 3 est disponible en téléchargement ... pour les chanceux abonnés à MSDN.

Pour les autres je suppose que le produit peut désormais être acheté chez Microsoft, au pire il s'agit d'une question de jours seulement.

Bon, je vous laisse, je viens de finir le download et je désinstalle Blend 3 beta le temps d'écrire ce billet et je vais maintenant installer tout ça !

Miam ! ... euhh Stay Tuned je voulais dire !

Silverlight 3 : Les Pixel shaders (effets bitmap) et l'accélération GPU

odahan.nospam@nospam.e-naxos.com (Olivier) — Tue, 28 Jul 2009 00:59:00 +0200

L'une des grandes nouveautés de Silverlight 3 c'est le support de l'accélération graphique. L'application principale se trouve déchargée de certaines tâches qui sont routées vers le GPU de la carte graphique. Mais attention, l'accélération GPU de Silverlight 3 ne fait pas tout comme sa grande soeur sous WPF (qui utilise DirectX et toutes ses ficelles pour accélérer le traitement vidéo). On aurait pu croire que les effets bitmaps (pixel shaders) de WPF qui viennent d'être portés sous Silverlight 3 utilisent l'accélération GPU, en réalité il n'en est rien. Mais cela n'enlève rien à ces nouveaux effets parfaitement utilisables pour enrichir le visuel d'une application et dont je vais vous parler maintenant...

Quelques mots sur l'accélération GPU : Même si ce n'est pas le sujet du présent billet, il s'agit d'une nouvelle feature très intéressante de SL3. On a tendance hélas (et j'ai été le premier à me faire "avoir") à trop vite faire le parallèle avec WPF et à transposer ce que fait l'accélération sous ce dernier. En fait, le support de l'accélération GPU de SL3 est pour l'instant assez limité et ne se met en route que de façon volontaire. Elle ne s'applique pas aux effets bitmaps ni aux nouveaux Codecs vidéos qui restent traités par le CPU. Malgré tout le système d'accélération graphique peut rendre d'immense service, dans certains de mes tests sur l'animation d'images assez grandes j'ai pu voir mon PC de test passer de 88% d'utilisation CPU (double coeur Asus plutôt rapide) à moins de 4% ! Ce qui est énorme. Mais pour profiter de l'accélération il faut aboslument en connaître le fonctionnement et les limitations. Je vous invite ainsi à lire l'excellent billet de Andras Verlvart sur la question. Il est assorti d'une application exemple qui permet de bien voir l'effet des différentes possibilités d'accélération et leur impact sur le CPU et le GPU. Cet article est en anglais, pour ceux qui préfère la lecture en français, David Rousset a écrit un billet qui fait le point sur cette même question.

Les Pixel Shaders

Par défaut Silverlight 3 est fourni avec deux effets : le blur (flou) et le drop shadow (ombre portée). Mais on trouve sur CodePlex un très beau projet offrant toute une série de nouveaux effets comme le swirl ou l'emboss (WPF Effects Library pour WPF et Silverlight). Grâce au SDK Directx et au langage HSL il possible de développer ses propres effets.

L'exemple ci-dessous illustre mon propos : la fenêtre principale est décorée d'une magnifique photo d'éclair (copyrigthée par moi-même) sur laquelle un flou peut être appliqué grâce à un slider se trouvant dans une petite fenêtre semi transparente sur laquelle est appliqué un drop-shadow.

Vous remarquerez que la petite fenêtre en question peut être déplacée par drag-drop grâce à une autre nouveauté de Silverlight 3 : les behaviors (comportements), sorte de petits bouts de code compilés qu'on peut "jeter" sur n'importe quel contrôle pour lui offrir le dit comportement, ici un déplacement par drag-drop. Le tout sans une ligne de C#. Le slider a été templaté "à l'arrache" mais il a été templaté tout de même :-). Autre nouveauté de Silverlight 3 qui est ici démontrée : le databinding entre éléments d'interface, ainsi le texte indiquant la quantité de flou appliquée est directement lié à la propriété Value du Slider. Pour formater cette valeur un convertisseur a été ajouté.

Bref, une petite application vite fait pour montrer les Pixel Shaders, mais pas seulement...

Le mieux étant maintenant de jouer avec et de télécharger le projet (VS2008 + SL3 toolkit ou Blend 3 de préférence) : PixelShader.zip (168,29 kb)

[silverlight:source=/SLSamples/PixelShader/PixelShader.xap;width=550;height=480]

Et Stay Tuned !

nota: cet article du 28 juillet 2009 a été mis à jour le 3 août à propos de l'accélération GPU.

Silverlight : Application transparente

odahan.nospam@nospam.e-naxos.com (Olivier) — Mon, 27 Jul 2009 06:23:00 +0200

Il est tout à fait possible de rendre une application (ou une fenêtre) Silverlight transparente, c'est à dire que son contenu apparaîtra sur la couleur de fond du site hôte. Cela peut s'avérer très utile pour des petits morceaux de Silverlight placés sur un site Html ou Asp.net, pour créer une barre de menu par exemple. Si la charte couleur du site est modifiée il ne sera pas nécessaire de modifier et recompiler la ou les applications Silverlight.

Pour arriver à ce résultat il faut faire deux choses simples dont la syntaxe dépend de la nature de la page où s'insère le plugin (ASP.NET ou HTML)

exemple ASP.NET :

<asp:Silverlight PluginBackground="Transparent" Windowless="true" ID="Menu" runat="server"

Source="~/ClientBin/Menuxap" MinimumVersion="xxxxx"  />

exemple HTML :

<object data="data:application/x-silverlight," type="application/x-silverlight-2-b2" >

<param name="source" value="ClientBin/Menu.xap"/>

<param name="onerror" value="onSilverlightError" />

<param name="pluginbackground" value="Transparent" />

<param name="windowless" value="true" />

</object>

Les deux paramètres importants étant : PluginBackgrounf et Windoless .

Par défaut une application Silverlight occupe 100% de la fenêtre hôte, dans le cas d'une barre de menu ou d'un autre type de fenêtre intégré à une page ASP.NET/HTML on ajoutera donc dans les balises la déclaration de la hauteur et de la largeur exacte qu'on souhaite réserver pour le plugin. Bien entendu le contenu de l'application Silverlight doit être dépourvu d'arrière plan, cela va sans dire, sinon, transparence ou non, c'est lui qui sera affiché et non le background de la page hôte...

Silverlight 3 : La multi-sélection

odahan.nospam@nospam.e-naxos.com (Olivier) — Thu, 23 Jul 2009 23:25:00 +0200

Parmi les petites évolutions de Silverlight 3 qui ne méritent pas un article de fond mais qu'il faut noter tellement elles simplifient les choses, j'apprécie le support de la multi sélection dans les ListBox.

La nouvelle propriété s'appelle sans malice : SelectionMode et elle peut prendre les valeurs suivantes : Single, Multiple, Extended. En mode Single on retrouve le comportement par défaut mono sélection. Les deux autres modes permettent d'accéder au comportement multi sélection. En mode Multiple la sélection s'opère par le clic sur un item, en enfonçant Ctrl ou Shift. Le mode Extended fait que le Shift permet de sélectionner des étendues.

Jouez avec notre ami Casimir dans l'exemple ci-dessous, et grâce à la nouvelle ListBox Silverlight 3 confectionnez votre propre Gloubiboulga en partant de la recette originale et de ses options (pour les plus gourmands !) :

[silverlight:source=/SLSamples/MultiSelect/MultiSelect.xap;width=411;height=203]

Bon appétit, et... Stay Tuned !

Silverlight 3 : Styles Cascadés (BasedOn Styles)

odahan.nospam@nospam.e-naxos.com (Olivier) — Thu, 23 Jul 2009 20:08:00 +0200

Toujours dans ma petite série sur les nouveautés de Silverlight 3 je vais vous présenter aujourd'hui une feature plaisante : les styles cascadés.

En soi rien de nouveau à l'ouest puisque c'est le principe même des feuilles de styles CSS (qui y puisent d'ailleurs leur nom). Mais le CSS s'applique à quelques éléments simples HTML alors que là nous parlons de styles Silverlight, c'est à dire d'objet complexes pouvant définir tout un visuel, animations comprises.

[silverlight:source=/SLSamples/BasedOnStyle/BasedOnStyle.xap;width=405;height=150]

Dans l'application Sivlerlight 3 ci-dessus (fonctionnelle, ce n'est pas une capture écran), vous voyez 4 boutons. Tous sont des boutons standard du framework.

Le premier, intitulé "Base SL" possède le style Silverlight par défaut
Le second, "Normal" est décoré par le style "BoutonNormal"
Le troisième "Gros" est décoré par le style "BoutonGros"
Et le quatrième "Alarme" est décoré par le style "BoutonGrosAlarme"

Visuellement c'est plutôt moche, je vous l'accorde, mais le but du jeu est de voir l'effet du cascading styling...

Le style "BoutonNormal" est défini comme suit :

<Style x:Key="BoutonNormal" TargetType="Button">

     <Setter Property="Width" Value="90" />

     <Setter Property="Height" Value="30" />

     <Setter Property="HorizontalAlignment" Value="Left" />

     <Setter Property="VerticalAlignment" Value="Bottom" />

     <Setter Property="BorderThickness" Value="2"/>

</Style>

Là où les choses deviennent plus intéressantes, c'est dans le style "BoutonGros" ci-dessous où l'on voit apparaître l'attribut BasedOn qui permet de fonder le style courant sur celui qu'on indique :

<Style x:Key="BoutonGros"

         BasedOn="{StaticResource BoutonNormal}"

         TargetType="Button">

  <Setter Property="Width" Value="180" />

  <Setter Property="Height" Value="60" />

  <Setter Property="FontFamily" Value="Comic Sans MS"/>

</Style>

Enfin, le dernier style se fonde lui-même sur le précédent par le même mécanisme, le niveau de cascading n'étant pas limité. On peut voir notamment que le changement de famille de fonte introduit dans le style "BoutonGros" s'est propagé au style "BoutonGrosAlarme" (fonte Comic).

<Style x:Key="BoutonGrosAlarme"

         BasedOn="{StaticResource BoutonGros}"

         TargetType="Button">

  <Setter Property="Width" Value="160" />

  <Setter Property="Height" Value="40" />

  <Setter Property="FontSize" Value="18"/>

  <Setter Property="FontWeight" Value="Bold"/>

  <Setter Property="Foreground" Value="Red"/>

  <Setter Property="BorderThickness" Value="4"/>

  <Setter Property="BorderBrush" Value="#FFFF0202"/>

</Style>

Voilà, c'est tout simple, mais cela peut radicalement simplifier la création de gros templates pour des applications. Tous les avantages du Cascading Style Sheet de HTML dont l'intérêt ne se démontre plus, mais appliqué à des objets et à la sophistication de Silverlight. Que du bonheur...

Bon Styling,

...Et Stay Tuned !