Version imprimable
Voilà,
J'ai passé tout l'après-midi à chercher sur le net un exemple qui explique comment on fait une recherche dans un listview et j'ai rien trouvé.
En WinForms c'est très compliqué (J'ironise bien sur) on fait comme ça:
ListView1.Items.Find("Blabla",True) et on a les correspondances !!!
Maintenant je souhaiterais savoir comment faire ça en WPF?
Merci
Quelque chose comme ça peut-être :
Pour utiliser la méthode d'extension Where il faut importer le namespace System.Linq.Code:ListView1.Items.Where(item => item.UnePropriete.Equals("Blabla"))
Merci mais cela ne fonctionne pas car Where n'existe pas même avec le using System.Linq !
Tu travailles bien avec une version de .Net >= 3.5 ?
Si c'est le cas vérifie que tu référence bien System.Core.dll.
Sinon il te faudra sans doute passer par une recherche directe dans ta collection en la parcourant entièrement.
je suis en 4.0 et j'ai bien la référence System.Core !
mais pas de where en vue.
Tu parles bien de WPF ?
Le problème vient du fait que la liste d'item n'est pas générique.
J'ai juste trouvé ce hack :
Code:ListView1.Items.Cast<LeTypeDesObjets>().Where(...)
Merci mais je n'avance pas plus !
que mettre dans la parenthèse du Where(...)
Et dire que tout le monre trouve super facile le WPF et companie :( plus j'avance et plus je trouve que ça régresse fort en productivité et tout ça pour de petite animation graphique........
Je penses que beaucoup vont se détourner de cette techno mais bon
Si tu n'as jamais utilisé Linq en effet ce n'est pas évident.
Sur quels critères cherches-tu à extraire des objets ?
Et bien je veux juste savoir quel est l'équivalent de:
ListView1.Items.Find("Hello")
pour un ListView en WPF ou plus généralement, comment fait on une recherche dans les Items d'un ListView en WPF
Merci
ba en fait les gens vont pas se détourner de cette techno car en fait tout le monde essaie de séparer proprement le code UI du code logique, grâce à des pattern design comme MVVM, maintenant évidemment si tu essaie de programmer en WPF comme tu programmais en winforms...
par conséquent, les gens s'amusent avec le code logique et l'exploration des vrais collections genre ObservableCollection ou sur les vues associées, que de travailler sur les données de l'UI...
seriousme... pour que Where soit disponible, de façon général il faut que la collection soit compatible (implante) IEnumerable / IEnumerable<>
le Where( ... ) attend en paramètre un prédicat qui prend en paramètre un élément et retourne un boolean indiquant si oui ou non il répond à une exigence.
ce prédicat est un délégué sur une méthode, une méthode anonyme ou une lambda-expression.
Il faut que tu comprenne que l'ui là stocke non pas un reflet texte des valeurs que tu as rangé dedans, mais bien les objets eux même... par conséquent, tu dois évaluer un critère sur ce type d'objet.
Si ton critère est la propriété NOM de tes objets,
tu aura un truc du genre
Where(x => x.NOM == "machin");
par exemple.
si maintenant tes objets sont des chaines...
Where(x=>x=="machin");
est le tour est joué.
ensuite pour récupérer l'élément, le seul sélectionné : Where(...).FirstOrDefault();
Ok,
C'est un peu plus clair comme ça. Mais pour avoir fouillé sur le net tout l'après-midi hier j'ai pas trouvé un exemple qui montre tout ça.
C'est à croire que personne n'a ce besoin !
pour mon application, j'ai un ListView que je rempli avec des TextBlock. Dans un TextBox je met un texte et sur l'évènnement TextChanged je souhaite rechercher dans le ListView si le texte saisi par l'utilisateur existe.
J'ai essayé de parcourir les contrôles de chaque ListItemView mais j'ai une erreur qui me dit que le ListView contient des XElement !!!
Donc je suis perdu de puis hier matin pour un truc qui m'aurait pris 10 minutes à faire en WinForms........
C'et le progrès :)
Salut,
Comparer WInForms et WPF ne ménera malheureusement à rien, il faut se dire que ce n'est absolument pas pareil dans la philosophie de développement et personnellement je trouve que WPF est bien plus évolutif et flexible que WinForm.
Bref mise à part ça, vu que tu as commencé en WPF as tu djéà jeté un coup d'oeil au pattern MVVM ?
A partir de la, vu que tu semble parser un XML tu peux très bien créer une classe Personne par exemple recevant les valeurs de chaque attribut d'un bloc.
Dans le MainWindowViewModel tu aurais une collection de PersonneViewModel que tu pourrais ensuite simplement filtrer en faisant :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Sans se servir du pattern MVVM ca me semble assez complexe à implémenter en fait, surtout quand on part d'un XML.
Concernant le parcours, il faudrait gérer de la façon suivante :
Code:
2
3
4
5
6
7
8
9
10
11
Chaque contrôle du DataTemplate est donc bindé à une des propriété de PersonneViewModel, on a donc bien les infos necessaires.
Concernant la recherche, il faut du côté des Command. De toute façon si tu t"interesse au pattern MVVM, tu verra un tuto sur developpez très interessant surtout pour ton cas (avec gestion de recherche notamment).
Je suis persuadé des performances du WPF mais ce que je trouve hallucinant pour ne pas dire débile c'est que dans tout ce qu'on lit sur le net à ce sujet, c'est qu'il faut faire des classes en plus, des delegate des predicate alors qu'en Winform tu as une instructions pour interroger ton treeview ou listview !!!!
C'est là que je bloque car pour moice n'est pas une évolution !
en VB3 4 5 ou 6 il fallait parcourir avec un For Each après en vb.net tu as eu une instruction .Find(). ça va dans le sens de l'évolution comme ça.
Maintenant il faut écrire des tonnes de lignes de code pour pouvoir interroger un ListView en WPF.
Merci je vais regarder du côté des MVVM alors....
Oui c'est sur il faut écrire beaucoup de plus de code mais ca fournit aussi une plus grande flexibilité. C'est malheureusement comme ca :s et si tu t'attaque à MVVM tu verra qu'il faut encore plus "écrire" de code :)
On écrit plus de code mais on s'y fait et on apprécie plus son code après ;)Citation:
Envoyé par obito
c'est clair, wpf nécessite plus de code, mais avec un pattern MVVM, le code est plus propre, plus facile à relire, plus facile à "prouver" avec des contrats, et plus facile à tester de façon unitaire...
adieu le code spaghetti et toute la logique dans le code behind...
du coup on y entre plus facilement, et le surcout en développement finalement passe carrément inaperçu.
et franchement à part le problème récurrent de la multi-sélection, non gérée en l'état, nativement, dans wpf... c'est carrément nickel.
l'ajout de code ne signifie pas systématiquement, ajout de complexité bien au contraire.
la flexibilité apporté par le surplut de code nécessaire vaut bien le sacrifice, et permet même dans certains cas d'avoir nettement moins de code qu'en winforms.
J'en suis persuadé mais là je pense qu'on parle de théorie car presque tout les exemples que je télécharge ne fonctionne pas !!!
Donc je veux bien que ce soit mieux etc....
Mais dans la pratique, on ne voit que des exemples à la HelloWorld.
Pour revenir à mon problème qui est la recherche d'un élément dans un ListView cela fait deux jours que je cherche et queje ne trouve rien de concret qui explique comment je fais une recherche dans un ListView en WPF.
Et je n'ai pas non plus de réponse sur le post :calim2:
Et puis dire que c'est plus propre etc....
Quand tu as tout considéré (Web.config, App.config, Styles.xaml, les views, les modelsview et j'en passe) je trouve pas que ce soit plus clair qu'avant moi!
J'aurais pensé que ça était un début de réponse :aie:Citation:
Envoyé par obito
En tout cas DotNET74 tu peux être frustré au début c'est compréhensible mais quand tu va commencer à t'y faire tu n'auras plus le même discours :) Concernant les exemples, je n'ai pas eu ce problème en revanche :) suffit de faire des "build" avant de lancer l'exécution et ca roule tout seul
là le problème c'est que tu persiste à essayer de parcourir la collection qui est stockée dans ta listview, au lieu de partir sur un modèle plus découplé, exposant une collection de données genre ObservableCollection<T>, ou pourquoi pas une vraie vue genre ListCollectionView
sur laquelle tu pourrais travailler plutôt que sur la listview elle même...
toute l'astuce consiste à laisser faire le databinding pour toi.
quand tu aura vraiment cherché les tutos et docs sur le pattern MVVM... crois moi, tu ne verras plus du tout les choses du même angle.
(genre de séquence de mots clé : wpf mvvm, si tu tappe mvvm tout seul ou wpf tout seul, tu va pas aller bien loin, et ce quelque soit le moteur de recherche.) Recherche essentiellement sur Bing ou google pour ce domaine particulier.
et effectivement l'exemple de obito est un excellent exemple et un bon début de recherche pour ton problème et pour débuter avec le concept de mvvm... puisque tu n'arrive pas à trouver sur une voie, essaie d'explorer d'autres sentiers, au lieu de buter toujours sur la même problématique... quand un problème est infranchissable, il faut parfois emprunter des sentiers détournés et emprunter les ruelles obscures...
Je suis certain que c'est un bon exemple....
Cependant, les fragments de code sont difficile à exploiter pour moi car je ne sais pas où les mettre :)
Bon ben ça fait une petite semaine que je bosse sur les deux tutos MVVM d'Olivier DAHAN de NAXOS.
Et je n'ai pas plus avancé !
la solution qu'on peut télécharger ne fonctionne pas, on a une belle page blanche au démarrage :)
C'est trop de la balle cette technologie :D
Après je suis tombé sur un article qui dit que Microsoft pense que Silverlight va compléter HTML 5.
Si c'est ça je pense que programmer comme ça (MVVM), cela ne va pas faire long feu parce que vu l'usine à gaz qu'il faut mettre en place pour gérer un pauvre click sur un bouton !!!!
On va coûter très chère à nos patrons :D
Bon j'y retourne mais pas avec une grande conviction !!!
8O need aussi mais un poil plus complexe.
Filtrer dans une ReadOnlyCollection qui est bindé dans un GridView, une valeur récupérer dans une TextBox (filtre sur nom et/ou prénom de ma ReadOnlyCollection qui sont les personnes). Et le plus drôle est que ce doit-être dynamique: c-a-d a chaque fois que j'appuie sur une touche du clavier :?
Je bosse dessus en ce moment si je trouve je mettrai mon code :ccool:
Je test pour le moment la solution de .Cast sur cette liste, je verrai bien
Bon j'ai réussit mon opération :ccool:
Par contre ce n'est pas dynamique :(
(ps: attention usine a gaz mvvm :P)
[XAML] au plus simple car normalement je passe par des userControl personnalisé par moi :mouarf:
[C#] mon ViewModelCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15<TextBox Text="{Binding SearchValue, Mode=TwoWay}" /> <!-- TextBox a remplir pour filtrer --> <Button Command="{Binding CommandSearch}"> <!-- Bouton lançant la recherche --> <ListView ItemsSource="{Binding personSearch}"> <!--ListView avec une List<IPerson> en source --> <ListView.View> <GridView AllowsColumnReorder="True"> <GridView.Columns> <GridViewColumn Header="ID" DisplayMemberBinding="{Binding Id}" Width="50" /> <!-- Binding de l'ID de ma source --> <GridViewColumn Header="Prénom" DisplayMemberBinding="{Binding FirstName}" Width="150" /> <!-- Binding deu prénom de ma source --> <GridViewColumn Header="Nom" DisplayMemberBinding="{Binding LastName}" Width="150" /> <!-- Binding du nom de ma source --> </GridView.Columns> </GridView> </ListView.View> </ListView>
[C#] Une Class IPerson pour comprendre le fonctionnementCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78//membre de ma class private RelayCommand m_CommandSearch; private string _SearchValue = null; private ReadOnlyCollection<IPerson> _persons; private List<IPerson> _personsSearch; //methode déclencher par un click du bouton public ICommand CommandSearch { get { if (m_CommandSearch == null) { m_CommandSearch = new RelayCommand(param => CanSearch(), param => Search()); } return m_CommandSearch; } } //propriété de ma classe. get et set des 2 list et de ma valeur de la TextBox public ReadOnlyCollection<IPerson> persons { get { return _persons; } set { _persons = value; OnPropertyChanged("persons"); } } public List<IPerson> personsSearch { get { return _personsSearch; } set { _personsSearch = value; OnPropertyChanged("personsSearch"); } } public string SearchValue { get { return _SearchValue; } set { _SearchValue = value; OnPropertyChanged("SearchValue"); } } public ViewModelPersonList() //Mon constructeur { persons = GetPersons(); //varaible me renvoyant une liste ReadOnlyCollection<IPerson> Search(); } //ca on s'en moque un peu c'est une partie usine a gaz du mvvm :? (si vous voulez mettre en false essayer vous verrez :) private static bool CanSearch() { return true; } private void Search() //methode me créant la second liste filtrer et bindé dans mon XAML { personsSearch = new List<IPerson>(); foreach (IPerson value in persons) { if (SearchValue == null || SearchValue == "") { personsSearch.Add(value); //renvoi tout si TextBox vide ou null (null c'est au demarage de la fenêtre) } else { if (value.FirstName.Contains(SearchValue) == true || value.LastName.Contains(SearchValue) == true) personsSearch.Add(value); //test et intégration si le prénom ou nom possède la valeur a filtrer } } }
Et donc par la suite j'ai un classe public class Person : IPerson que vous devez surement savoir comment construire ^^Code:
2
3
4
5
6
J'espère avoir aider ou mis sur la voie si ta recherche ne ce fait pas le manière comme je le fait ^^.
quelle usine à gaz ?
ya rien de bien mortel la dedans...
en plus il existe MVVM Light, un bon petit framework tiers qui s'intègre à Visual studio pour te faciliter la vie quand tu développe avec ce pattern, que ce soit en WPF ou Silverlight.
ne croit pas que parce que tu n'y trouve aucun intérêt il n'y en a pas, et que cela n'est pas plus productif... bien au contraire.
quand on parle d'un projet ou d'un gros produit, le plus long ce n'est que rarement le développement.
le plus long c'est la phase de tests et débogages. heureusement certains bugs sont évités, lors des tests unitaires, ou des preuves non respectés quand on programme par contrat, et donc facilement isolables...
mais les bugs plus vicieux qui représentent 90% des bugs de ton application, ce sont eux qui vont justifier quand tu vend un produit, une maintenance corrective...
plus tu maximise le découpage, le faible couplage entre UI et logique, plus tu permet de mieux maintenir la logique, plus efficacement, avec ce pattern, les tests unitaires sont possibles sur quasiment tout le viewmodel, ce qui diminue d'autant la possibilités de bugs inhérents à la logique de ton code.
ensuite, quand on doit modifier une vue pour des raisons X ou Y et que cela n'a aucun impact sur la logique, il est plutot sympa de ne pas toucher à la logique du tout...
si un designer ou un ergonome doit retoucher à ta vue, et que toutes les informations exposées par le viewmodel suffisent, à priori la modification ne portant que sur le XAML... on est gagnant car là aussi on réduit les bugs inhérent à toute modification.
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
ça fait deux semaines que j'essai de bien comprendre comment ça fonctionne et comment le mettre en place donc je ne remets pas en doute l'intérêt.
Maintenant mon constat est le suivant:
J'ai télécharger pas mal d'exemple pour comprendre et il y en a plus de 90% qui ne fonctionnent pas quand tu ouvres le code source.
Bref!
pour résumé là où j'en suis:
imaginons une Page avec un bouton dessus. C'est donc mieux de créer un ViewModel et un Model pour gérer les évènements du bouton.
Si c'est bien ça la philosophie, pourquoi le bouton est fourni avec tout ces évènements ????
Simplement (c'est mon avis personnel) car tout ces évènement ont été laissé pour les gens habitué et continuant a développer avec.
S'il supprime tout ces évènements, cela reviendrait a obliger tout le monde a développer en modulaire selon les propres goûts de Microsoft. Si c'était le cas je préférerai même pas imaginer le nombre de développeur qui pousserai leur gueulante ><.
Par contre derrière ces évènements sont toujours utilisable en mvvm mais complexe a mettre en place (je dit ca un peu normal ca fait a peine 3 semaines que me suis mis au mvvm).
Quelle utilité de laisser faire les gens avec des méthodes qui de toute façon ne permettent pas de faire les chose (voir mon problème initiale) puisque dans un ListView WPF qu'on souhaiterais programmer en utilisant pas MVVM on ne peut pas faire de recherche dans les Items du ListView car il n'y a rien qui est prévu...
là je ne comprends plus alors..
Et, puis tout les exemples (de chez Microsoft) que j'ai téléchargé et analysé je n'ai jamais vu de MVVM.
En ce moment, je bosse sur un tuto pour faire un puzzle en Silverlight sous WindowsPhone et là aussi....
pas de MVVM.
alors les exemples Microsoft principaux, sont fait pour devinez qui ??? la grande majorité des gens, et j'entend par là, les non initiés aux best design & practices.
si tu veux des exemples Microsoft sur le MVVM, ce n'est pas sur le site de microsoft que tu les trouveras, mais dans les blogs de gens qui travail chez microsoft ou des MCPD.
le problème c'est que souvent, ces exemples là s'adressent déjà à une catégorie de développeurs initiés, mais pas tous.
tiens quant à dire que microsoft ne parle pas de MVVM...
http://msdn.microsoft.com/fr-fr/magazine/dd419663.aspx
c'est la MSDN... on peut gère faire plus ouvrage de référence dans le domaine. C'est écrit par Josh Smith lui même, la référence sur le sujet. Il y a son site, mais bon là effectivement c'est en anglais, et c'est pas trop adapté aux débutants mais bon...
tu peux t'intéresser également sur developpez.net
et j'ai trouvé des tas de trucs rien qu'en tapant MVVM dans Google...
les blogs sur "tech head brothers" sont souvent assez sérieux.
maintenant personne n'a jamais dit que les exemples étaient tous exempts de bugs, ou que les solutions compilent... mais bon souvent ce n'est pas là pour être compilé tel quel mais plutôt pour montrer le code comme proof of concept.
Microsoft recommande d'utiliser le databinding avancé de WPF, et il n'y a que le pattern MVVM qui permette de réellement en exploiter toute la puissance.
encore une fois il faut faire un distinguo entre les exemples du tout à chacun, et les recommandations.
Quant à l'usage des évènements à l'ancienne, personne n'a dit qu'ils étaient prohibés en MVVM. lorsque le gestionnaire de clic par exemple est très simple et qu'il n'implique que de l'UI et pas du tout de logique métier, même Josh Smith y a recours, dans certains de ses exemples.
Maintenant si tu es un développeur plus aguerri sur la plateforme, et un peu puriste comme moi, tu sortira l'artillerie lourde des behaviors et tout le toutim, mais même là parfois un ptit gestionnaire d'évènement onclick est salvateur et évite des tonnes de lignes de code.
Il ne faut pas non plus sombrer dans le fanatisme absolu, et être fermé à toutes les autres options, sous prétexte que l'on ne veut plus de code behind.
Je ne me considère pas comme un initié !
L'informatique n'est pas mon métier de base bien que j'ai pas d'expérience professionnelle dans ce domaine, je suis juste un passionné qui programme depuis l'âge de 10 ans (donc ça fait 28 ans !!!) et qui commence à ne plus rien comprendre :aie:
après un an de stop, je me remets dedans et étant quelqu'un de rigoureux je veux faire bien.....
Mais c'est pas gagné pour moi
PS: merci pour votre aide
bien disons que là on touche plus à la méthodologie qu'au développement lui même et c'est là que cela coince au final.
c'est une nouvelle doctrine, une nouvelle approche (pas si nouvelle que cela en fait, c'est un peu le saint graal du développement, ce type de pattern, et donc ses prédécesseurs et précurseurs)
le problème est que comme personne n'apprend à réellement séparer les responsabilités, et même pas à l'école pour ceux qui auraient suivit des études dans le domaine.
il est difficile de fournir des exemples appliquant des principes comme MVP, MVC ou maintenant MVVM pour WPF, sous peine de larguer d'office absolument tout le monde.
de même on est tout à fait conscient que ce genre de développement engendre un surplus de code, mais l'apport en vaut la chandelle, et donc il ne convient pas à des exemples simplistes sur un sujet quelconque, car il faudrait quasiment systématiquement reprendre sur le fondement même du modèle choisi plutôt que sur le problème traité par l'exemple.
Je reconnais que cela n'aide pas, et que cela n'améliore pas la situation, de quelque part, laisser cela aux initiés ou experts...
mais comme tout le monde le fait, si je puis dire, ceux là même qui écrivent sur ces sujets, finalement, s'adressent généralement à des auditoires avertis, et ne prennent donc pas le temps de revenir aux béaba, et c'est fort dommage.
en même temps, la référence msdn s'adresse clairement à des utilisateurs avertis, mais josh smith a écrit un livre qui lui s'adresse à un auditoire de tout horizons normalement, enfin d'après les critiques que j'ai entendue sur le sujet.
Je comprends tout à fait.
Mais si, c'est LA nouvelle façon de programmer WPF et Silverlight, il faut que Microsoft ne perde pas de vue que si c'est aussi innabordable, beaucoup de programmeurs (comme moi) vont se tourner vers d'autre langages....
Ce n'est pas LA nouvelle méthode de programmer, et je dirais que ce pattern se met en place là où il y a des architectes qui comprennent le principe (enfin en même temps un architecte qui n'entrave rien à ce principe a vivement intérêt à changer de job)...
Cette méthodologie à l'intérêt de permettre la rationalisation des ressources et du développement, en maximisant les tests unitaires en diminuant la phase de tests et de corrections postérieures, ce qui permet de mieux gérer les développeurs et de les affecter à d'autres projets.
Cela permet également dans les entreprises où on trouve des développeurs et des designer, de ne plus se battre parce qu'ils ne parlent pas la même langue...
Cela facilite aussi pas mal le développement en équipe, y compris quand il y a des designers dans l'équipe.
Aussi, ce type de pattern devrait être de mise en entreprise, et il l'est dans certaines, cependant il n'est pas indispensable.
Il fait parti des bonnes pratiques, best practices, conseillées par Microsoft pour utiliser ses technologies, destinées avant tout aux professionnels qui font du développement logiciel, un métier.
il est toujours possible de faire du code spaghetti en WPF, une bonne pratique n'est pas obligatoire...
Après tout, tout le monde sait que l'alcool et le volant ne font pas bon ménage... rien n'interdit toutefois de boire et de conduire... la voiture démarre. Tu n'a pas le droit de te faire prendre... ou d'avoir un accident, ce qui, ici, est analogue à un bug critique (avec certes plus de conséquences).
les développeurs ne changeront pas de technologie juste parce qu'ils ne connaissent pas ce pattern...
si ce pattern était obligatoire, tu n'arriverais pas à compiler le moindre projet sans utiliser cette technique, et il n'aurait pas fallut attendre Silverlight 4 pour avoir le support natif des Commandes (et encore c'est loin d'être aussi poussé que sous WPF)... avant il fallait carrément sortir les bons vieux behaviors, et là il y avait vraiment de quoi être découragé.
la seule plateforme qui est très "fermée" et limitative sur son modèle c'est ASP.NET MVC... effectivement tu es obligé d'utiliser le pattern MVC (Model View Controller) pour développer avec ce framework.
Quand au fait que tu a des bribes de code... oui, mais je ne suis pas convaincu que te montrer un exemple complet qui compile et tout soit si éducatif que cela. La plupart du temps, il faut se demander pourquoi les solutions fournies en exemples ne compilent pas... souvent c'est pour des vulgaires fautes de frappes, ou des étourdissements.
Et puis assembler ces bribes de code dans tous les sens (vive le copy/paste) t'oblige à apprendre, surtout s'il faut les modifier ces bribes de code. Apprendre par toi même par l'essai-erreur.
C'est certes beaucoup plus long, mais nettement plus formateur.
Pour finir il ne faut pas non confondre langage et plateforme/technologie.
Le langage qu'il soit VB.NET ou C# ne change rien à l'affaire.
Quand à WPF... et bien il n'existe pas d'équivalence, avec autant de souplesse, sur une autre plateforme.
Éventuellement Qt qui une bonne plateforme, mais bon... c'est du natif, et c'est nettement moins souple que WPF.
Et pour les RIA ba, le choix est plutôt restreint et il ne reste au final que
Adobe Flash(/Flex) et là c'est plus du tout la même chose... c'est contreproductif, l'environnement est une pure catastrophe, et totalement anti-collaboratif (le support de subversionning par utilisation des modules eclypse ne sert à rien, vu qu'il n'ajoute aucune option particulière dans l'interface... en fait les modules en règle générale ne servent à rien)
et désormais les développeurs flash se retrouve dans le même environnement que flex, fini le bel IDE bien chiant avec les timeline, et entièrement graphique. Ils veulent copier Microsoft avec le MXML, mais vu que le code behind (et tout le code en général) doit figurer dans le MXML... on est pas rendu, c'est ultra illisible.
Au final, quand on connait la concurrence de Microsoft, crois moi on s'accommode des quelques défauts et on est bien heureux comme cela.
Salut,
Des exemples concrets, il y en pas mal maintenant sur la toile. En voici un de Josh Smith sur les TreeView avec deux exemples démo. Le premier correspond à ta problématique de recherche. Ces exemples utilisent le pattern MVVM.
Voici le lien :
http://www.codeproject.com/KB/WPF/Tr...ViewModel.aspx
Comme je l'ai dis c'est appliqué au TreeView donc plus complexe que pour une ListView, mais si tu comprends son article, ce sera d'autant plus facile pour toi ;)
En regardant vite fait sur google, j'ai d'ailleurs ce lien qui apparait du même auteur ;)
http://joshsmithonwpf.wordpress.com/...-in-a-listbox/
Dans les deux liens, le projet est téléchargeable.
Sinon sans passé par MVVM (car même si cette pattern est plutôt sympa, elle n'est pas obligatoire) :
XAML :
code behind :Code:
2
3
4
5
6
7
8
9
10
11
Quand tu seras plus à l'aise avec cela, tu pourras eventuellement commencer à regarder la pattern MVVM :)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48// Classe Personne public class Person { public string Title { get; set; } public string Description { get; set; } } private List<Person> persons = new List<Person>(); public MainWindow() { InitializeComponent(); for (int i = 0; i < 100; i++) { persons.Add(new Person() { Title="Hello" + i , Description = "Super" + i } ); } // on met les persons dans le controle this.MonListView.ItemsSource = persons; // Recherche de la personne de titre Hello5 dans la collection mais pas dans le controle Person result = persons.Find((p) => p.Title == "Hello5"); // sinon tu peux faire un foreach si tu es plus à l'aise Person result = null; foreach( Person person in persons ) { if( person.Title == "Hello5" ) { // trouvé person = person; } } }