WPF signe la fin des Windows Forms ?

Citation:

---

Envoyé par davcha

Un exemple "tout con" : l'affichage d'une liste sous forme de cartes de visite, par exemple. Ou encore l'affichage de plus d'une seule information dans une combobox.

---

D'accord mais est ce que pour réaliser certains trucs tout con en winforms ce n'est pas plus compliqué avec WPF pour l'instant ?

Par exemple, nos utilisateurs adorent les représentations sous forme d'arbre (treeview). Ils adorent aussi pouvoir trier sur n'importe qu'elle colonne, les sous totaux, les images dans les treeview et les bulles d'infos quand ils ne savent plus a quoi ca sert.

En winforms ce genre de chose n'est pas particulièrement compliqué à faire. Est ce qu'avec WPF tu peux faire tout ca rapidement ?

Une petite question, en passant, sur cet intéressant débat (sur lequel je n'ai pas d'avis, n'ayant pas encore tâté du .Net 3) : WFF, c'est un nouveau truc, ou c'est simplement WWF (le système de workflow) avec un doigt qui a ripé ?

Citation:

---

Envoyé par npuzin

Par exemple, nos utilisateurs adorent les représentations sous forme d'arbre (treeview). Ils adorent aussi pouvoir trier sur n'importe qu'elle colonne, les sous totaux, les images dans les treeview et les bulles d'infos quand ils ne savent plus a quoi ca sert.

En winforms ce genre de chose n'est pas particulièrement compliqué à faire. Est ce qu'avec WPF tu peux faire tout ca rapidement ?

---

Oui, ce genre de choses peut-être fait rapidement ;)

Citation:

---

Envoyé par Guulh

Une petite question, en passant, sur cet intéressant débat (sur lequel je n'ai pas d'avis, n'ayant pas encore tâté du .Net 3) : WFF, c'est un nouveau truc, ou c'est simplement WWF (le système de workflow) avec un doigt qui a ripé ?

---

Il devait s'agir d'une erreur de frappe: on parle bien de WWF (Workflow) et pas WFF ;)

Voilà je remonte le sujet pour connaitre en 2010 le bon choix technologique.

J'ai développé quelques petites applications en C# / Windows Forms, mais je compte maintenant développé de plus grosses applications. Que faut-il choisir au début d'un nouveau projet ?

Citation:

---

Envoyé par PocoYote

Voilà je remonte le sujet pour connaitre en 2010 le bon choix technologique.

J'ai développé quelques petites applications en C# / Windows Forms, mais je compte maintenant développé de plus grosses applications. Que faut-il choisir au début d'un nouveau projet ?

---

Ben Windows Forms n'est pas encore mort, mais c'est en perte de vitesse alors que WPF est de plus en plus utilisé. Il n'y a qu'à comparer le nombre de discussions sur WPF dans le forum aujourd'hui et il y a 1 an ou 2 pour s'en rendre compte...

En plus WPF est infiniment plus souple que Windows Forms, et permet de réaliser assez facilement de jolis effets graphiques

Si tu peux te permettre de ne pas adresser les postes Windows < Windows Xp sp2, WPF semble un choix plus judicieux à l'heure actuelle.

Merci pour vos conseils.

Mes postes cibles seront XP, Vista, Seven et Server 2003. Dommage pour Windows 2000 quand même. La plupart de mes développements seront des applications clientes "lourdes".

Donc je regarderai WPF en priorité.

Après avoir fait quelques petits tests en Windows Form et en WPF pendant mon temps libre, je ne suis pas arrivé à faire hériter une fenêtre en WPF. En faisant une petite recherche sur Google, je suis tombé sur un article de Thomas Lebrun qui indique que l'on ne peut pas faire d'héritage sur du code XAML... En Windows Form, il n'y a aucun problème.

Je trouve que cela est vraiment un problème pour du développement rapide, et remet même en question le choix de WPF (dans mon cas). Depuis mes premiers développements (Borland C++ 5 en 1995 !), je n'ai jamais vu cette limitation sur aucun système. Il s'agit quand même de la base du développement objet.

Est ce que cette limitation va disparaitre ? Qu'en pensez vous ?

Citation:

---

Envoyé par PocoYote

Après avoir fait quelques petits tests en Windows Form et en WPF pendant mon temps libre, je ne suis pas arrivé à faire hériter une fenêtre en WPF. En faisant une petite recherche sur Google, je suis tombé sur un article de Thomas Lebrun qui indique que l'on ne peut pas faire d'héritage sur du code XAML... En Windows Form, il n'y a aucun problème.

Je trouve que cela est vraiment un problème pour du développement rapide, et remet même en question le choix de WPF (dans mon cas). Depuis mes premiers développements (Borland C++ 5 en 1995 !), je n'ai jamais vu cette limitation sur aucun système. Il s'agit quand même de la base du développement objet.

Est ce que cette limitation va disparaitre ? Qu'en pensez vous ?

---

Tu peux le faire, mais pas si la fenêtre dont tu hérites est définie dans le même assembly. Et de toutes façon je n'ai jamais eu besoin de faire ça en WPF, il y a toujours d'autres méthodes plus adaptées. D'ailleurs même en Windows Forms j'ai toujours trouvé cette possibilité parfaitement inutile...

Citation:

---

D'ailleurs même en Windows Forms j'ai toujours trouvé cette possibilité parfaitement inutile...

---

Cela n'engage que toi !

Si par exemple, je définis une fenêtre standard d'importation de données, et que j'ai envie de spécialiser cette fenêtre pour une classe (en ajoutant une option par exemple), je suis coincer en WPF (ou alors si j'ai bien compris, il faut passer par une DLL, ce qui alourdi vraiment les manipulations).

Plus globalement, en langage objet, l'héritage est fondamental pour tous les objets (une fenêtre étant un objet comme un autre). Personnellement, j'ai beaucoup utilisé cela dans mes précédents développements...

Citation:

---

Envoyé par PocoYote

Cela n'engage que toi !

---

Je ne dis pas le contraire ;)

Citation:

---

Envoyé par PocoYote

Plus globalement, en langage objet, l'héritage est fondamental pour tous les objets

---

Oui, à condition de l'utiliser correctement. Et l'utiliser correctement, c'est l'utiiser dans un sens sémantique, et pas pour réutiliser du code (dans ce cas, c'est de l'héritage d'implémentation et on peut le qualifier, le plus souvant, d'erreur de conception).

Oui l'héritage technique est encore trop utilisé de nos jours (et par des architectes expérimentés en plus...) :?

C'est pas non plus si terrible que cela et n'a pas plus de conséquence que cela en fonction des projets et dépend de la taille et des relations des objets.

Cela reste un défaut de qualité interne certes cependant cela n'empêche pas d'avoir une qualité externe acceptable (même si en général une qualité interne mauvaise limite la qualité externe)

Salut,

pour les fenêtres héritées, je l'ai déjà fait en passant par une classe abstraite intermédiaire (=> la classe abstraite hérite de Window ou d'une de tes fenêtres personnalisées, et pour la fenêtre dérivée tu auras MyWindow.cs et dans le xaml ça commencera par un truc du genre <local:MyWindowBase x:class=xxx.MyWindow.cs).
Je ne l'ai fait qu'une fois et ne le referai jamais, car même si ça fonctionne c'est tout simplement monstrueux niveau conception !
Pour ton exemple d'import de données, je verrai plutôt une Window basique avec un datatemplateselector si besoin :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

class A { public string Name{get;set;} }   class B : A { public string Description {get;set;} } ****** <DataTemplate DataType="{x:Type local:A}" x:Key="templateA"> <TextBlock Text="{Binding Name}"/> </DataTemplate>   <DataTemplate DataType="{x:Type local:B}"> <StackPanel> <ContentPresenter Content="{Binding}" ContentTemplate="{StaticResource templateA}"/> <TextBlock Text="{Binding Description}"/> </StackPanel> </DataTemplate>   <

---

Ce genre de trucs est très efficace avec les interfaces (pas besoin de spécifier le DataTYpe des DataTemplates, et tu peux faire de la composition dans tes contrôles, par ex. quand tu as beaucoup de classes qui implémentent des interfaces à toi dans tous les sens).

Citation:

---

Oui, à condition de l'utiliser correctement. Et l'utiliser correctement, c'est l'utiiser dans un sens sémantique, et pas pour réutiliser du code (dans ce cas, c'est de l'héritage d'implémentation et on peut le qualifier, le plus souvant, d'erreur de conception).

---

Oui je comprends. Mais je ne vois pas pourquoi en particulier l'héritage d'une fenêtre n'aurait pas un sens sémantique... (exemple en QT : QDialog => QAbstractPrintDialog => QPrintDialog)

Bon maintenant il faudrait que je me penche sérieusement sur WPF, pour pouvoir comprendre comment contourner le problème (comme ce que me propose MetalGeek).

Bonjour,

Je déterre le sujet pour relancer le débat.
Nous sommes bientôt en fin d'année 2011 est ce que maintenant il est primordial de se tourner vers WPF par rapport au WInForm ?
Est ce qu'il faudrait même transformer en WPF nos applications existantes winForm ?

Citation:

---

Envoyé par bugland

Bonjour,

Je déterre le sujet pour relancer le débat.
Nous sommes bientôt en fin d'année 2011 est ce que maintenant il est primordial de se tourner vers WPF par rapport au WInForm ?
Est ce qu'il faudrait même transformer en WPF nos applications existantes winForm ?

---

Démarrer ex-nihilo un développement sur Winform actuellement est sans doute un choix un peu douteux.

De là à convertir les applications existantes Winform en WPF, hors refonte importante nécessitée par des besoins fonctionnels, il y a un pas; de plus, tu m'expliqueras comment tu justifies cela auprès de ta DSI sur un plan budgétaire, sachant que pour l'instant il n'y a aucun arrêt prévu du support de cette techno.

Même avis que Bluedeep

Essaye déjà de convaincre la DSI de passer au WPF pour les nouvelles applications ;)