Dans la catégorie je veux faire le plus beau site du monde mais mon budget est inférieur à 5 euros, hébergement compris : Un ensemble de composants gratuits pour silverlight :

http://www.webresourcesdepot.com/free-silverlight-controls-and-tools-for-brighter-websites/

Ne soyez plus amnésique sur les concepts fondamentaux de .net : tout ce que vous devez savoir sur la gestion de la mémoire en .Net : http://geekswithblogs.net/sdorman/archive/2008/09/14/.net-memory-management-ndash-resources.aspx

nAML : une nouvelle façon graphique de modéliser ses application .NET ?
Lecture intéressante même si UML semble avoir encore de beaux jours devant lui :

http://www.codeproject.com/KB/dotnet/naml.aspx

Backlight ! Non ca ne permet pas (encore de rétro éclairer vos écrans) mais cela devrait cependant permettre d’afficher de jolies choses dessus. Backlight est un ensemble de composants graphiques pour les technologies « riches » de Microsoft. Pour le moment centré sur silverlight la diversification technologique devrait apparaitre bientôt.

http://www.codeplex.com/blacklight

Marre de travailler, envie de jouer ? La béta de XNA game studio 3 vient de sortir :

http://creators.xna.com/en-us/3.0beta_mainpage

Envie d’avoir un site propre et dynamique ? C’est le moment de le récurer : un peu de lecture sur Ajax ne fera pas de mal :

http://www.codeproject.com/KB/aspnet/AjaxQuickFAQ.aspx

Comment faire de jolis diagrammes sans plomber le budget pour impressionner votre boss et avoir une augmentation : SEdit est un éditeur de diagramme de séquence gratuit

http://sdedit.sourceforge.net/index.html

Afin de proposer un produit le plus fiable possible, je cherche des personnes souhaitant participer au beta testing. Si vous êtes intéressé, envoyez-moi un message privé.

Plus d’information : www.aflava.com

Terminons sur une petite note visuelle et graphique : une petite capture d’écran :

Outils

• Comment créer votre propre extension à l’interface de visual studio 2008 : http://blogs.msdn.com/quanto/archive/2008/01/22/building-your-own-visual-studio-source-code-outliner-extension.aspx:
• Un bel exemple fourni avec son code source permettant d’avoir une vue arborescente de son code « à la réflector » : http://coolthingoftheday.blogspot.com/2008/01/source-code-outliner-10-powertoy-for.html

Langage

• Comment éviter de casser la compatibilité avec les anciennes versions lorsque l’on développe une bibliothèque de fonctions/composants : http://codebetter.com/blogs/patricksmacchia/archive/2008/01/20/avoid-api-breaking-changes.aspx
• Blinder votre code afin de le rendre plus résistant et tolérant : http://devlicio.us/blogs/derik_whittaker/archive/2008/01/22/defensive-coding-best-practice.aspx

Bibliothèques / composants

• Un composant diagramme prometteur : http://www.codeproject.com/KB/library/columnchartgenerator.aspx
• Ce n’est pas un nouveau composant mais il commence à atteindre une certaine maturité et il y a de nombreuses questions récurrentes sur le forum quant à la recherche de ce genre de grille. http://www.devage.com/Wiki/ViewArticle.aspx?name=sourcegrid&version=0
• Faire du MDI avec WPF : http://www.codeproject.com/KB/WPF/mwiwpf.aspx

Tendances :

• Une implémentation d’openId en c# : http://blog.madskristensen.dk/post/OpenID-implementation-in-Csharp-and-ASPNET.aspx
• Microsoft vient de publier une nouvelle version de son langage fonctionnel F# http://research.microsoft.com/research/downloads/Details/7ac148a7-149b-4056-aa06-1e6754efd36f/Details.aspx

Quelques liens:

• En video
• Le site du projet

Je me devais en cette fin d’année 2007 de faire le point sur l’avancée du projet. C’est chose faite avec ce billet.

Tout d’abord commençons avec la capture d’écran rituelle. Même si elle ne permet pas de se rendre compte de l’utilisation réelle du framework, elle donne cependant une bonne idée de ses possibilités actuelles.


Je profite de ce billet pour dire que je recherches des personnes intéressées pour de l’alpha et du bêta testing. En effet, la bibliothèque arrive à un stade où je souhaiterais commencer à recueillir l’avis de développeurs sur son utilisation. Pour le moment c’est plus une phase de « CTP » qu’autre chose, la bêta viendra après.
Si vous désirez y participer, vous pouvez me contacter par message privé.

Voici les grandes avancées depuis le dernier résumé :

Fonctionnalités de « popup »

Par popup j’entends tout widget s’affichant sur une autre fenêtre que celle en cours d’utilisation. Cela regroupe pour le moment la ComboBox, la supertooltip ainsi que le menu contextuel.
J’ai voulu que l’architecture du framework permette d’étendre facilement ces popups, en pouvant par exemple ajouter sans restriction, tout type de widget à un ContextMenu.
Les popups disposeront également de fonctionnalités permettant de les redimensionner.
Les popups ne sont pas windowless, c’est-à-dire que chaque popup est basé sur un control et possède donc un handle. Cela va un peu à l’encontre d’un de but du framework mais proposer des popups windowless aurait été trop contraignant pour l’utilisateur (impossibilité pour le popup de déborder de la fenêtre l’hébergeant).

Supertooltips

Grande nouveauté introduite par Office 2007, tout framework d’UI se doit de posséder une telle fonctionnalité.
Chaque widget peut donc avoir une supertooltip optionnelle.
Ses fonctionnalités sont les suivantes :

• Forme de la tooltip modifiable via le thème.
• Support de la transparence.
• Rendu et disposition modifiables via le thème.

Petit aperçu :

Autres avancées :
Outre ces 2 grandes fonctionnalités, le framework a subit une foule de petits changements et d’optimisations. Le hit testing ainsi que le redessin des widgets sont maintenant 2 fois plus rapides.

Comme toujours n’hésitez pas à réagir / critiquer / suggérer. A bientôt pour un autre épisode. :o)

En attendant bon réveillon et à l’année prochaine!

Pour les personnes, qui ne se souviendraient pas du but du projet, il consiste à créer une bibliothèque de composants légers pour les Windows Forms 2.

Les choses ont bien avancées depuis le dernier résumé et le toolkit commence même à être un peu utilisable.
Le mode design permet maintenant :

• d’ajouter/supprimer des widgets
• de réorganiser les widgets à l’aide du drag and drop
• de copier coller les widgets
• de les mettre en forme (alignement, …)
• de modifier leur propriétés.

Même si certaines de ces fonctionnalités peuvent paraître très basiques, elles ont été développées spécifiquement afin d’avoir un mode design pour les widgets proche de celui des autre controls.

En parallèle de la gestion du mode design, un certain nombre de widgets ont été développés :

• label
• bouton
• panel
• checkbox
• tabcontrol
• statusbar
• listbox
• textfield
• …

Certains de ces widgets sont pour l’instant incomplets, l’étape suivante consistera à les rendre pleinement fonctionnels ainsi qu’à leur ajouter des petits camarades afin qu’il se sentent moins seuls.

Un de but de ce framework étant de fournir « une bibliothèque pratique, performante et simple à utiliser » (dans la mesure du possible), je suis intéressé par toute remarque, commentaire ou demande de fonctionnalité.
Si vous avez déjà été confronté à une limitation gênante des windows forms n’hésitez à me la communiquer.

Voici un aperçu de ce que l’on peut faire (capture faire sous Windows XP):

Plus d’information et téléchargement ici: www.aflava.com

N’hésitez pas à réagir si vous avez des bug à reporter ou des améliorations à suggérer.

Architecture de la bibliothèque

Il fallait trouver un moyen pour avoir des widgets héritant de component ayant un comportement similaire à des control, aussi bien en mode design qu’en utilisation normale.
La solution adoptée reprend le principe utilisé par les toolstrips : un control (héritant de parentcontrol) servant de conteneur hôte aux différents widgets utilisés.
La bibliothèque contiendra peut-être plusieurs types variante d’un tel control. On s’attachera pour l’instant à la seule existante : HostSurface, une surface d’accueil de widgets.
Afin de fournir une bibliothèque conviviale il nécessaire d’avoir un mode design riche et pratique à utiliser. Pour ne pas mélanger l’aspect design et celui runtime, chaque widget pourra avoir une classe designer associée (héritant de componentdesigner)

Les widgets de base

Ils sont au nombre de 2. Le premier est le plus simple et la base de tous. Son Nom ? WidgetBase. Il fourni toutes les propriétés et fonctions communes à ses futurs héritiers.
Entre autres :

• Gestion du paint (gestion de l’arrière plan ainsi que le premier plan)
• Gestion du clavier
• Gestion de la souris
• Diverses propriétés d’apparence et de comportement.

Premier héritier et second widget de base : ContainerWidgetBase. Sa seule différence avec WidgetBase est de pouvoir contenir une collection de widgets.

Ces 2 widgets de base ont chacun leur designer associé : WidgetBaseDesigner et ContainerWidgetBaseDesigner.

Premier Widget : le panel

Un précoce ce panel, à peine né et déjà parent (de widgets) ! En effet le premier widget est un conteneur. La raison principale est qu’il me fallait un widget racine pour la surrface hôte.
Concrètement le panel n’est pas encore terminé et fourni pour le moment uniquement
Des fonctionnalités basiques (pas de moteur de layout évolué par exemple)

Le mode design
Les bases (comprendre le strict minimum) du mode design ont été implémentées. A savoir :

• Sélection des widgets
• Gestion du hit testing (et gestion des conteneurs)
• Sélection primaire et secondaire
• Service d’ajout de widget à un widget conteneur existant (via le petit « + »)

Exemple de sélection multiple avec 1 panel à bord arrondi et un autre transparent.

Menu d’ajout de widget

Où nous en sommes :
On peut maintenant créer des panels imbriqués, les sélectionner à la souris en mode design ainsi que changer leurs propriétés à l’aide de la property grid. Rien de bien utilisable dans une application concrète (où alors vous êtes très imaginatifs )

J’essaierais dans les étapes suivantes de rendre la bibliothèque plus utile en développant en parallèle 2 aspects :

• L’ajout de widgets (label, checkbox, …)
• L’amélioration du mode design (permettre de redimensionner un widget à l’aide de ses poignées de sélection, fournir une meilleure intégration à Visual Studio…)

A bientôt pour le prochain épisode !

• Etre léger: ne pas dériver les contrôles de control mais de component afin d’avoir des contrôles « windowless« . Inconvénient principal de ce choix: avoir presque tout à réinventer, que ce soit le comportement à l’exécution ou le comportement lors du design. C’est le principal obstacle qui pourrait affecter le projet.
• Etre simple à utiliser: comprendre développer un mode design agréable. Là encore, dériver de component ne facilite pas les choses et de nombreuses choses seront à re-développer.
• Etre facilement personnalisable, via l’utilisation de renderers
• Proposer 3 renderers par défaut: un système, un reprenant le style utilisé par windows et un autre se rapprochant du style Office2007.
• Fournir des composants supportant le databinding (simple au début, plus évolué par la suite)
• Ce point est un objectif secondaire: fournir un système d’animation simplifié des composants permettant de réaliser des animations basiques. Il n’est pas question ici de mettre en place un système d’animation aussi perfectionné que celui de WPF mais juste de permettre de rendre un peu plus vivant les contrôles.

A cette liste déjà assez difficile à implémenter, il est toujours possible d’ajouter des fonctionnalités si elles apportent quelque chose d’intéressant. N’hésitez donc pas à communiquer vos idées !

Q: Pourquoi privilégier winform alors que WPF est déjà sorti?

R: Je considère WPF comme une technologie très prometteuse. Cependant elle est encore très jeune et je fais parti de ceux qui pensent que winform a encore de très belles années devant lui. De plus il apparaît qu’une même application réalisée avec WPF est souvent plus lente et moins réactive qu’une autre réalisée en winform. Il me semble également que toutes les possibilités de winform n’ont pas encore toutes été épuisées et qu’il est sûrement possible de réaliser avec de beaux projets.

Q: Encore une nouvelle bibliothèque de contrôles? Il en existe pourtant beaucoup et de qualité!

R: Oui c’est vrai il existe déjà sur le marché de nombreuses bibliothèques de composants dont la plupart sont de qualité. Pourquoi en créer alors une nouvelle? Je suis parti du constat que la plupart des bibliothèques de contrôles existantes dérivent de system.window.form.control. Les composants winform standard eux aussi dérivent de control. En fait .Net « wrap » les contrôles existants de windows.

Cela présente un inconvénient majeur: la majorité des contrôles disponibles (label, button, …) sont en fait des windows. La conséquence est qu’un formulaire contenant un nombre conséquent de contrôles est souvent lent.
Un autre problème est la personnalisation du rendu de ces contrôles. Ce problème est partiellement résolu par la version 2 du framework qui permet un « ownerdraw » pour certains contrôles (listbox, treeview, …). Cependant des personnalisations simples sont difficiles, comme par exemple changer la couleur d’une bordure d’une textbox.

Pour toutes ces raisons, je pense qu’il y a de la place pour une nouvelle bibliothèque de composants. Un bon exemple de ce qu’il est possible de faire est le système de « Toolstrip » introduit dans la version 2 du framework. En effet ce système est léger (peu de handles utilisés), extrêmement personnalisable (utilisation de renderers) et possède un mode design agréable à utiliser.