Discussion :

[Kropernic]

Du peu que je l'ai testé, WPF est quand même fondamentalement différent sur la manière d'interagir avec l'interface graphique.

Enfin, je pense qu'il y a toujours moyen de travailler plus ou moins comme en winforms mais, de ce que j'ai cru comprendre à l'époque, on passe à côté de WPF dans ce cas.

Niveau design, c'est sur qu'en winforms, on ne fait pas de dégradés de couleur, de jolis boutons en étoiles ou autres et que c'est toujours le cpu qui s'occupe de la partie graphique mais, pour des applications de bureau, je pense que ce n'est pas forcément nécessaire. Après, les goûts et les couleurs...

La grosse question que l'on se pose chez nous (et il n'y a malheureusement que moi qui tente d'y répondre quand j'ai 5 minutes) c'est est-ce que winforms sera toujours utilisable avec win8 et win10 ou bien faut-il commencer à développer dans une autre techno pour ne pas devoir réécrire d'ici 3 ans ce qu'on développe aujourd'hui...

[BlackAlpha]

Théoriquement si le WPF et WinForms n'est que présentation, il faudra juste refaire l'interface, le code restera le même non ?

[youtpout978]

Théoriquement si le WPF et WinForms n'est que présentation, il faudra juste refaire l'interface, le code restera le même non ?

Non, à part si tu as vraiment bien découper ton code que tu n'a pratiquement rien dans le codebehind de tes forms, mais dès que tu utilises un control Winforms il faudra réécrire cette partie de code pour utiliser l'équivalent WPF.
Sinon mets toi y maintenant c'est pas du temps de perdu et une fois que tu le maîtrisera bien WPF tu ne voudra pas revenir à WindowsForms, tu trouvera plein de tuto génial sur ce site.

[Pragmateek]

J'ai lu un peu en diagonale ce qui a été dit. Par contre j'ai quelques questions de "confirmé".
J'ai appris le VB puis ai passé au C#, le tout en utilisant WinForms et il est certain que lorsqu'on est développeur et qu'on se soucie peu du design WinForms est tout simplement un plaisir.

Néanmoins ce que je cherche est quand même d'actualiser un peu le design de mes applications, faire un effort de présentation du moins. J'ai lu que fondamentalement on peut avoir recours au WPF comme au WinForms (même si on passe a coté du potentiel de la chose), du coup je me pose la question sur la courbe d'apprentissage, si je passe au WPF (connaissant déja le WinForms), j'apprendrais forcément à mieux l'utiliser au fil du temps non ?

En effet faire du "beau" et du personnalisé est infiniment plus aisé avec WPF qu'avec WinForms et pour certaines applications cela peut être une raison suffisante pour migrer si l'aspect visuel est important pour les clients et que l'application concurrente s'y met aussi.

Par contre dans le cadre d'une entreprise où la clientèle interne est captive l'intérêt est bien moindre et dans ce cas autant acheter une bibliothèque de composants WinForms tiers pour quelques centaines d'€.
Ça reviendra bien moins cher que de refaire en WPF.

[Pragmateek]

La grosse question que l'on se pose chez nous (et il n'y a malheureusement que moi qui tente d'y répondre quand j'ai 5 minutes) c'est est-ce que winforms sera toujours utilisable avec win8 et win10 ou bien faut-il commencer à développer dans une autre techno pour ne pas devoir réécrire d'ici 3 ans ce qu'on développe aujourd'hui...

WinForms et WPF reposent tous deux sur la même stack technique au niveau de l'OS, l'API Win32 (et en plus WPF utilise DirectX).
Donc si Microsoft tue Win32 alors WinForms et WPF seront tous deux out.
Pour le moment Win32 est toujours là Microsoft ayant juste ajouté une "meilleure" API Windows, WinRT.
Et je pense qu'il n'y a aucun risque de voir disparaître Win32 car s'il y a bien une chose que Microsoft prend au sérieux c'est la rétrocompatibilité, surtout qu'il serait contre-productif d'un point de vue commercial d'empêcher les clients d'acheter les nouvelles version de l'OS sous prétexte qu'ils ont des applications reposant sur Win32.

Donc aujourd'hui pour faire de nouvelles applications LOB sous Windows WPF est à utiliser sans hésitation.

[draco951]

J'ai commencé à développer sur Winform et suis passé après en WPF pendant 2 ans.
Au début, quel galère ... ! Plusieurs fois, j'ai été tenté de laisser tomber mais j'ai persévéré et ca en vallait vraiment la peine.
Etant donné que je ne trouvais pas de tutoriel intéressant ni de doc suffisante, je m'obstinais à travailler en wpf comme en Winform et c'étais une grosse erreur, après la découverte du MVVM je me suis rendu compte du potentiel du WPF :

La customisation, la puissance du binding, la découpe des couches, la qualité du code, ... Tellement de choses merveilleuse ...

Je travail à nouveau sur winform suite à un changement de job et c'est pour moi une méchante régression, j'espère arriver à convaincre mes collègues de switcher sur WPF mais vu le manque de temps pour la formation ... c'est pas gagné :-)

Si vous en avez l'occasion, n'hésitez pas, et foncez sur WPF !

[I_Pnose]

J’ai lu les deux pages en diagonale, du coup il y aura certainement des redites.

Je ne vais pas revenir sur le couplet concernant la pérennité de Winforms ; c’est une techno mature qui n’évolue certes plus mais qui fait son job sans sourciller, et vu qu’on voit mal Microsoft amputer son OS de la plateforme Win32 (à l’heure actuelle cela représenterait 99,9999% du parc logiciel Windows qui irait directement à la benne... source venant de moi-même grâce à un pifomètre extrêmement bien calibré =P), on peut acter le fait que la techno peut être utilisée sans scrupule.

Maintenant la question, dois-je migrer sur WPF ? Fondamentalement, la réponse sera au cas par cas ; un éditeur de logiciel qui veut se démarquer de la concurrence avec un truc à la fois fonctionnel et sexy, aura peut-être plus de marge de manœuvre avec WPF qu’avec Winforms. Une boite de service qui développe des outils pour les besoins internes de sa production, et qui accessoirement possède une équipe de devs sevrée à Winforms, peut-être que dans ce cas de figure le passage à WPF n’est pas urgent (mais la veille techno ça ne fait pas de mal ^^).
Au-delà de ça il y a un autre aspect ; on le sait, Winforms est plutôt doué dans la création rapide de formulaires (formulaires de gestion par exemple, dont on se fout généralement un peu de la beauté), de plus le tout est plutôt léger et tournera sur les machines les moins pourvues (abstraction faire de la complexité des traitements métiers, bien évidemment). A l’opposé, WPF est très à l’aise dans tout ce qui va être application graphique, mais en contrepartie le programme sera plus lourd à exécuter (et souvent les chipsets intégrés des machines d’entreprise sont un peu limite... surtout quand le dev tombe dans tous les pièges de WPF). Au regard de ceci, je pense qu’un dév C#, sous couvert qu’il maitrise WPF, ne devrait pas écarter Winforms impunément de ses choix technologiques (et c’est un fervent fanatique de WPF qui parle).

Un petit mot sur la mobilité. J’adore le développement Windows Phone 8.1 et Windows 10 (surtout Windows 10, le RelativePanel, le rendu itératif des Templates de liste, les VisualState Trigger, etc... je veux tout ça dans WPF !), mais soyons pragmatiques, dans un milieu pro ces technos ne ciblent pas suffisamment de monde pour que ce soit un choix technologique optimal. Et surtout, il existe une machine de guerre qui a fait ses preuves ; j’ai nommé Xamarin. Le seul défaut qu’on peut lui trouver c’est son prix non négligeable pour un indépendant (avis perso... et ne venez pas me parler de la version gratuite ! un développeur C# ça développe dans Visual Studio =P).
C’est d’ailleurs avec un projet Xamarin qu’on se rend compte de tous les bienfaits de MVVM (le fameux, qui donne des maux de tête au débutant) ; du code métier que l’on peut brancher à une IHM Android, WindowsPhone, iOS... si l’app mobile dérive d’un client lourd WPF et qu’on a bien respecté le pattern MVVM, le boulot est déjà bien mâché (tout dépend du client lourd, bien évidemment... il y aura certainement des ajustement à faire au niveau de la DAL, et la source de données devra sans doute être déportée quelque part dans un nuage... Azure pour ne pas le citer ; une autre machine de guerre).

Pour revenir vite fait sur WinRT (le pauvre), c’est plus ou moins un fiasco avéré sur Windows 8.x (moi-même j’ai beau apprécier l’OS, les apps plein écran, en dehors d’une tablette, trop peu pour moi), cela dit, un dev qui souhaite faire une application native Windows Phone 8.1 (et qui n’envisage pas Xamarin), je ne lui conseillerais pas de bannir ce choix technologique au profit systématique de Silverlight ; sur le papier les apps WinRT sont plus performantes que les apps Silverlight, et les apps WinRT permettent de créer des Universal Apps à moindre frais.

Bref, vu que je suis parti pour écrire un roman et qu’à priori d’autres ont répondu aux questions posées, je vais peut-être m’arrêter là.

[tomlev]

WinForms et WPF reposent tous deux sur la même stack technique au niveau de l'OS, l'API Win32 (et en plus WPF utilise DirectX).

WPF ne repose pas sur Win32, à part pour la fenêtre qui contient l'application. Tout ce qui se passe dedans est complètement indépendant de Win32 (par exemple tu n'as pas un HWND pour chaque contrôle, contrairement à WinForms)

[fiduce]

WinForms est toujours d'actualité ! ;-)
Je viens de coder un projet from scratch avec ! (un petit truc : 1 mois de boulot, deux logiciels dont l'utilitaire qui m'a permis de bosser à distance sur une simulation de l'environnement de déploiement). Pas de grosse difficulté mais quand même un peu de socket (5 ouverts en même temps, avec des réceptions non-sollicitées) et donc du multithreading.

Franchement, je ne vois pas ce que j'aurais fait de la vectorisation de l'interface : le soft ne sera utilisé que sur un seul PC tout ce qu'il y a de plus standard et qui sera dédié à ça. J'étais bien content de bosser en pixels quand il s'agissait d'afficher des bitmaps (schémas récupérés dans des PDF, en copie d'écran !) sans effet de stretching ... et sérieusement, dans le monde du PC, le FullHD représente l'écrasante majorité des écrans (depuis un bon bout de temps).

DataBinding ? Pas de data gérées en BDD dans ce projet. 11000 lignes de code en tout. Le soft est générique : je l'ai codé pour qu'il sache exactement gérer le genre d'écrans dont j'avais besoin, puis j'ai créé une centaine d'écrans en utilisant mon soft en mode design. Les 100 écrans sont répartis en une dizaine de séquences de tests. Les écrans peuvent contenir des tas de trucs comme des boutons déclenchant des actions (ça va du simple test de connexion à un instrument à des trucs beaucoup plus compliqués impliquant 20 minutes de réglages/mesures automatiques, en passant par la correction de réglages pour caler une mesure à une valeur souhaitée) et des tableaux de mesures répétitives (c'était un gestionnaire de banc de tests ... mais au début j'ai développé le simulateur du banc vu que je savais que j'en verrai pas la couleur : un petit utilitaire qui permet d'envoyer des messages en divers protocoles et qui sait se mettre aussi en "man in the middle" pour sniffer toutes les requêtes et réponses, de sorte à pouvoir simuler ultérieurement le banc. Il y a du logging sérieux dedans aussi (des traces détaillées, pour avoir des dumps en hexadécimal et des timings de temps de réponse précis permettant de fixer des timeout réalistes). Je précise que j'ai tout développé sans même voir mon client une seule fois : strictement tout a été fait au téléphone et avec 2 sessions teamviewer).
J'avais une spécif assez pourrave de rang 2 ... et aux 3/4 du projet, comme je râlais, j'ai eu la spécif de rang 1 aussi (nettement meilleure, mais pourrave quand même !). J'ai bossé en me basant uniquement sur les docs constructeurs des instruments à piloter.
Le plus laborieux a été l'activité d'édition des explications de chaque écran (des zones RTF mixant photos et textes) et le fait qu'il n'y avait pas deux instruments causant le même protocole (il y avait du GPIB, du modbus, etc, même un bus CAN et sa passerelle ethernet ! ;-) ).

Coté contrôles un peu complexes, il y a un treeview assez customisé (celui des séquences et étapes de tests, qui affiche en icône des nœuds leur état : fait ou pas fait, stoppé en cours de route, obsolète, etc), des datagriview, et un tabview pour lequel je génère des contrôles à la volée quand l'utilisateur ajoute des tab (à partir de formulaires template présents dans le projet, mais qui ne servent que de control factory WYSIWYG : je ne les instancie jamais de façon visible). Mes fenêtres se rappellent leur place (même en multi-écran). Le soft principal affiche une fenêtre globale (qu'on met sur un bord de l'écran normalement) et des successions de fenêtres de tests (de taille différente), dont on peut régler le positionnement par défaut (par exemple les coller bord à bord avec la fenêtre globale, ou les caler toujours dans un coin d'un écran, ou placer leur centre à un endroit d'un écran, etc).
Dans le simulateur de banc (qui ne fait pas partie du livrable, mais qui a quand même été codé dans le mois), il y a 3 zones resizables qui se répartissent l'espace à l'intérieur d'une fenêtre resizable (2 barres de fraction invisibles déplaçables).

Je donne des détails pour que ce soit clair que c'est pas le jeu du pendu : c'est pas hyper-compliqué, mais c'est pas trivial nonplus. Et je donne aussi des détails parce que sur les forums, on a l'impression qu'il n'y a que des softs à "prépondérance data" en informatique. Purée, mais si vous saviez ! Il y a pas mal de gens qui codent des trucs interactifs qui ont une logique autrement plus élaborée, et où vous pouvez toujours aller vous brosser si vous voulez séparer l'IHM de la logique : c'est juste pas envisageable. Même document/view n'est pas utilisable (sauf, évidemment, si on s'enquiquine à faire un document qui reprend exactement les contrôles de la view ... mais dans ce cas ça ne sert à rien : on ne gagne rien).
Et vous pouvez toujours essayer d'utiliser 75% des technos qu'on retrouve dans le camembert des langages les plus utilisés : tout ça ne vous servira strictement à rien. Mais on ne voit que ça dans les offres d'emploi (qui sont complètement biaisées par les SSII qui cherchent des profils bien particuliers pour attaquer les gros projets juteux, et qui sont nombreuses à même ne plus se positionner sur les autres projets, ou alors pas au forfait).

J'en ai marre qu'on nie ce qui fait un bon 60% des projets que je réalise, et le reste du temps, j'écris des docs (STB, études de secteur, etc) ou je fais de la théorie en recherche opérationnelle pour proposer des améliorations à certains clients.

Le plus amusant est que j'ai à peu près reproduit le principe de WinForms dans mon projet : j'ai un mode design qui permet de définir un mode runtime. Pour chaque écran j'ai aussi des ressources (par exemple le fichier RTF qui s'affichera dans la zone des explications, que je peux afficher/modifier dans wordpad). Je peux "compiler" ma base d'écrans (qui est une sous-arborescence du file system sur mon PC de design) en un seul fichier "un peu codé pour ne pas être modifié par l'utilisateur".

Bon j'ai un peu bradé ce projet, mais c'était un nouveau client et dans ce cas, je fais toujours un peu de dumping (j'en connais qui auraient vendu ça 3-4 mois facile, même en étant capables de prendre le projet par le bon bout ... et de ne pas utiliser cette daube de NI-Teststand suggérée au départ, qui m'aurait pris 10 fois plus de temps pour un résultat minable).
(y a même une doc cette fois ! ;-) nan je rigole, y a toujours une doc. On peut revoir tous les résultats dans le soft, refaire une séquence ... et le rapport sort au format Excel (10 pages en une seconde : j'ouvre un modèle de feuille de calcul en automation, je colle toutes mes data (en une seule instruction) sur la feuille prévue pour ça, et les autres feuilles se mettent à jour ... en fait, les tableaux de chaque feuille sont "insérés par image" en feuille principale, ce qui fait un truc assez propre une fois imprimé ...et l'utilisateur peut très facilement modifier le modèle et compléter les rapports, par exemple s'il veut ajouter des formules testant certaines mesures).
Le soft gère en persistance un repository de "cobayes" testés (il y a un "fichier de cobaye") qui est enrichi au fur et à mesure des tests passés. On peut donc tester une séquence le lundi, et la suivante un autre jour, si par exemple on préfère passer 10 cobayes au premier test avant de passer au second. On peut revoir les tests déjà passés dans l'IHM (mode read only grisé). Je gère aussi les dépendances entre les séquences de tests, et une notion de "résultat global dépendant du résultat de chaque sous arbre" : si on refait un test basique, par exemple suite à une modification du cobaye (changement d'un composant, etc), des tests ultérieurs peuvent être invalidés (et donc à refaire) ... je gère une notion d'utilisateur aussi, et j'archive la date/heure de chaque action ... en fait j'ai codé un générateur de tests, et 100+ écrans qui l'exploitent). Enfin je gère en persistance des caractéristiqes statiques/globales, transverses à tous les cobayes, et qui dépendent les caractéristiques du banc. Ces dernières sont affinées lors de chaque test, mais au moins on ne part jamais de zéro.

Ok, ça fait 2 jour que je viens ici en rajouter ... il faut croire que ma comptabilité annuelle me pousse vraiment à faire autre chose ;-)

[redcurve]

Excellent sujet.
Je pense que WPF et Winforms ont une durée de vie similaire en termes de support.
Si "Windows X" devais radicalement revoir la couche desktop et supprimer le support de Winforms alors WPF subirait certainement le même destin.

Nous avons fait le choix il y a 3 ans de passer sous WPF et nous ne le regrettons pas, MVVM peut être contraignant mais reste un avantage, la liste des composants (éditeurs tiers) est plus conséquents, on sort des boutons coloré ^^ et ce peut être un plus pour le marketing, sans oublier Blend qui est magique.
Le problème de performance de WPF a tendance à s'atténuer et aujourd'hui, à partir de Zéro, je prendrais WPF.

Ne pas confondre WPF et XAML, l'énorme avantage est sur Xaml est une abstraction du coup le moteur (wpf) pourrais très bien disparaitre sans affecter Xaml. A ce sujet le travail en cours sur Xaml standard va dans ce sens à terme il n'y aura plus qu'un seul framework UI cross plateforme et vectoriel.

[mister-gaets]

WPF, c'est de la merde !

Désolé d'être grossier, mais je suis du genre à ne pas mâcher mes mots.

Trop de complications pour manipuler les listes déroulantes dans les dataGrids
(impossible d'écrire dans une cellule "liste" avec un DataTable),

Impossible de lire ou d'écrire dans une cellule après l'initialisation de votre dataGrid avec un DataTable,
si vous utilisez TextBlock, Combobox ou CheckBox en fonction de la nature de votre cellule ;

Avec Windows Forms, vous avez une ligne qui se crée automatiquement quand vous ajoutez des colonnes (pas avec WPF, et je n'ai jamais obtenu d'aide à ce sujet),

Si vous utilisez les datagrid{type}Columns, c'est une aberration, car vos données sont perdues lorsque vous avez terminé
la saisie et que vous changez de cellule (SAUF avec les cases à cocher !!!)

Insertion très complexe des cases à cocher dans un TreeView... Et j'en passe !

J'ai relevé trop d'anomalies dans WPF ! Ras-le-bol de ne jamais pouvoir développer des applications fonctionnelles !!

En revanche, je n'ai jamais ces problèmes avec Windows Forms.
Aucune raison que votre cellule se vide sans arrêt après validation !

Conclusion : utilisez Windows Forms, ça ira mieux.

[Pol63]

lol
Wpf ne s'utilise pas comme Windows forms...
Apres oui wpf n'est pas exempt de défaut mais rien de rédhibitoire je trouve

[youtpout978]

Il faut oublier les pratiques winforms avec wpf, en windows forms tu agis sur l'affichage, en wpf plutot sur les données.
Si tu veux ajouter une ligne a une "datagrid", il vaut mieux ajouter un nouvel objet à ta collection qui est lié à ton datagrid, si tu veux récupérer les données d'une ligne tu récupères l'objet lié à cette ligne et tu lis directement la donnée dedans ...