Je viens de finir un bon bouquin de base sur WPF : Pro WPF in C# 2008, de Matthew MacDonald (Editions Apress. ISBN-10: 1-59059-955-1. ISBN-13: 978-1-59059-955-6), et les pages 904 et 905 ont retenu toute mon attention. Elles listent les contrôles ou fonctionnalités manquantes en WPF par rapport à WinForms, et expliquent ce qu’on peut avoir en équivalence.
Ce genre de liste est évidemment très intéressante pour un architecte logiciel, car c’est de l’information concentrée sur les limites d’une migration de WinForms à WPF. Par contre, c’est sur la version 3.5 de .NET, et je n’ai pas réussi à retrouver cette information mise à jour pour .NET 4.0. Du coup, je m’y mets… Par contre, vu que je débute en WPF, si vous avez des informations supplémentaires, ça serait sympa de mettre un petit commentaire, car je vais laisser pas mal de rubriques à vide.
LinkLabel
Utiliser plutôt un Hyperlink dans un TextBlock. Pas de changement évidemment sur la version .NET 4.0. Personnellement, je ne pense pas que c’était un manque, mais plutôt une modification bienvenue, car le contrôle LinkLabel en WinForms était vraiment bizarre. Par exemple, pourquoi avoir un LinkArea permettant de délimiter le lien, alors que conceptuellement, les morceaux de texte n’en faisant plus partie devrait être des labels ? Si on a besoin de modifier le texte pour des questions de ressources, on se retrouvait avec des mots anglais découpés en fonction de la taille des mots français !
MaskedTextBox
Le livre propose de créer son propre composant en utilisant System.ComponentModel.MaskedTextProvider. Du coup, je me suis intéressé à cette classe. Il s’agit en fait d’un formateur fonctionnant avec un masque, mais sans retour graphique. Du coup, l’intégration à une zone de texte est relativement simple, et surtout, elle peut être réalisée sur n’importe quel autre contrôle. Cette URL est particulièrement détaillée.
Il existe peut-être des contrôles commerciaux qui reproduisent un MaskedTextBox en WPF, mais personnellement, je pense qu’il vaut mieux continuer à utiliser la solution du bouquin, car si un jour vous avez besoin de valider des données en provenance d’un autre type de contrôle, ou même d’incorporer ce comportement dans un traitement métier, ce sera beaucoup plus élégant de passer par un contrôle sans affichage.
DomainUpDown / NumericUpDown
Le bouquin propose de mettre en place un contrôle avec un TextBox et deux RepeatButton. Ca me paraît un très bon exemple d’une caractéristique à mon sens très importante de WPF, à savoir que le système de template réduit quasiment à néant le besoin de construire ses propres UserControl. Typiquement, ces deux contrôles ne sont que des TextBox en termes de fonctionnalités, à la différence que deux boutons sont rajoutés dans le template modifé.
CheckedListBox
Logiquement, ceci n’existe plus vu qu’on peut customiser librement un ListBox avec un template comprenant un checkbox. L’autre solution consistant à mettre plusieurs checkboxes dans un ScrollBox ne me paraît avoir aucun intérêt, vu qu’elle ne permet pas le binding, et surtout qu’elle n’est pas plus simple à faire que la solution sur une ListBox.
DataGridView
La plupart des fonctionnalités qui ne sont pas présentes de base dans WPF sont faisables avec un peu de code, et sinon, il y a ComponentOne qui fait de très bons contrôles WPF, avec plein de features super, et des versions Silverlight.
WebBrowser
Il semblerait qu’il y ait du nouveau en .NET 4.0, car Visual Studio 2010 montre bien un composant WPF WebBrowser :
Du coup, pas besoin de passer par la méthode du livre qui consistait à afficher un frame, avec la grosse limitation associée qui était qu’on n’avait pas accès au DOM. Là, on a bien de l’interaction possible. Un gros ouf pour celui-ci… et une bonne raison pour migrer de WinForms directement à WPF 4.0 plutôt qu’avec une étape par le 3.5.
PropertyGrid
Je ne vais pas parler de ce contrôle, parce que je ne sais pas du tout à quoi ça sert. J’ai jeté un oeil sur internet, et il se trouve que c’est un composant qui, comme son nom l’indique, sert à afficher les propriétés d’un objet, comme dans le dock de propriétés de Visual Studio par exemple.
Je n’aurais pas pensé que ce genre de composant était livré dans .NET. C’est vraiment le genre de trucs avancés que je m’attendais à ce que Microsoft nous laisse faire, mais bon… pourquoi pas. Mais du coup, je comprends tout à fait que ça n’ait pas passé le cut pour être intégré dans WPF.
ColorDialog, FolderBrowserDialog, FontDialog, PageSetupDialog
Le bouquin explique qu’on peut utiliser ceux de WinForms ou les recréer relativement facilement. A mon avis, ça sera très vite dans votre framework de contrôles communs. Et encore une fois, il y a des revendeurs de contrôles très bons et pas très chers.
PrintPreviewControl, PrintPreviewDialog
Je vous renvoie au bouquin, je n’ai rien à dire là-dessus, par manque de connaissance. Par contre, je serais très intéressé par les commentaires de gens qui font de la création de documents pour imprimantes en .NET.
ErrorProvider, HelpProvider
Ca me paraît sidérant qu’il n’y ait pas de solution pour ceci en WPF, tellement c’est important. Encore une fois, mes connaissances de WPF sont trop limitées, mais ça ne m’étonnerait pas qu’il y ait quelque chose pour la gestion de l’aide, même si ce n’est pas sous la forme d’un contrôle.
Au passage, les contrôles de type Provider créait une sorte d’inversion des propriétés entre le contrôle et la cible qui me paraît très proche des attached properties.
AutoComplete
Je ne savais même pas que c’était incorporé dans WinForms, et je me suis d’ailleurs retrouvé à le recréer. Si j’avais su… Du coup, le manque ne me paraît pas criant en WPF, surtout que beaucoup de gens ont une approche différente, et il me semble difficile d’avoir une seule façon de faire, donc c’est peut-être mieux comme ça, plutôt que de risquer avec une méthode intégrée d’avoir des problèmes de mauvaise utilisation.
Rien à voir avec ce sujet, mais j’ai découvert dans ce bouquin ou un autre que la correction orthographique était intégrée dans WPF ! Même chose : pour mon boulot, j’ai testé différentes façons de faire, dont de l’interop avec Office ou OpenOffice, et des contrôles commerciaux pour ceci. Bonne nouvelle : si on passe en WPF, je n’aurais pas besoin de tout ça. Yes…
MDI
Bon, alors là, pour le coup, je n’ai pas d’idée nouvelle sur le sujet, vu que je n’ai jamais en dix ans de carrière développé une interface MDI. Honnêtement, je me demande des fois si ça sert vraiment, ce truc. Autant un système comme les applications à base de pages me paraît vraiment une super innovation de WPF (ça fait déjà plusieurs fois que je crée des frameworks pour rendre ce genre de chose plus facile dans mon boulot), autant le MDI…
Bref, je suis intéressé par savoir si beaucoup de gens utilisent ceci, et comment ils ont décidé de le réaliser en WPF.
Conclusion
Cet article ne servira à rien sans vos commentaires. N’hésitez pas, c’est gratuit 🙂 Et comme vous le voyez, je ne connais pas grand chose à WPF, donc cet article est plus un appel à expérience sur les migrations et WPF. Merci par avance.
