Combobox : détecter ajout/retrait élément

"Delf" <abuse@orange.fr> a écrit dans le message de groupe de discussion :
49306205$0$25299$426a34cc@news.free.fr...

Le 28/11/2008, Gloops a supposé :

Ah, toi aussi, tu penses aux délégués.
Mais surcharger la classe juste pour le plaisir d'écrire des délégués ...

Ouais, j'y ai pensé.
Sinon en C# 3.0 on ne peut pas ajouter des méthodes dans les classes du
framework ? Je ne sais plus comment ça s'appelle mais p'tre ajouter
AddWithEvent(), RemoveWithEvent(), etc... non ?

A tout prendre, un héritage serait à la fois plus simple et plus fiable
qu'une méthode d'extension.

Plus fiable parce que rajouter une méthode ne peut pas garantir que
l'utilisateur n'appellera pas l'ancienne (Add).

Plus simple parce qu'une méthode d'extension n'est qu'un sucre syntaxique
pour une fonction statique, pour laquelle les events que tu créerais
devraient à leur tour être statiques pour pouvoir y être appelés (avec donc
pour conséquence que tu ne pourrais avoir qu'un unique gestionnaire
d'évènement appelé pour l'ensemble de tes listes).

Christophe Lephay a écrit, le 28/11/2008 23:25 :

Plus simple parce qu'une méthode d'extension n'est qu'un sucre
syntaxique pour une fonction statique, pour laquelle les events que tu
créerais devraient à leur tour être statiques pour pouvoir y êt re
appelés (avec donc pour conséquence que tu ne pourrais avoir qu'un
unique gestionnaire d'évènement appelé pour l'ensemble de tes lis tes).

Oh, je me rends compte qu'on aborde des points intéressants, là.

Mon application a juste une liste déroulante à synchroniser avec un
fichier, mais c'est vrai que pendant qu'on y est on peut étendre.

J'aime bien l'expression sucre syntaxique :)
Il faut que je bosse un peu pour en apprécier toute la saveur, mais ç a a
l'air joli.

Christophe Lephay a écrit, le 26/11/2008 20:46 :

BindingList<string> ma_liste = new bindingList<string>();
ma_liste.ListChanged += MonEventHandler;
ma_listbox.DataSource = ma_liste;

....

Bon, il semble finalement que le travail que j'ai fait sur les délégu és
ne soit pas surdimensionné, ni même hors sujet, pour suivre la conver sation.

ça m'a permis par exemple de comprendre comment faire pour que la
procédure soit acceptée pour l'assigner au délégué, à savoir lui passer
le bon type de paramètres et la dériver du bon type de procédure.

Au départ, j'avais compris qu'il s'agissait de convertir (cast) la list e
combinée déroulante en BindingList<string>.

Comme je me suis fait jeter à ce niveau-là (erreur CS0030), j'ai rega rdé
d'un peu plus près l'exemple fourni dans l'aide en ligne (pas avec un
BindingList<string> mais avec un BindingList<Part>). En fait, c'est un
peu plus sioux que ça, l'un doit agir sur l'autre, c'est bien ça ?

Donc, l'interface doit non pas créer un nouvel élément dans la list e
combinée déroulante, mais dans la BindingList, et c'est celle-ci qui va
le répercuter dans la liste combinée déroulante.

Et la BindingList n'a pas d'interface propre, en dehors de la liste
déroulante qu'on va explicitement mettre à jour via le délégué.

Ai-je bien perçu l'esprit de la chose ?

Bonjour tout le monde,

Ok pour l'expression sucre syntaxique :) ,...

Mais par contre pas trop pour le côté static : Pourquoi?
1) oui on déclare une méthode statique dans une classe statique hors de
la calsse à étandre.
2) le premier argmuent est une instance de la classe étandue :) et oui
UNE instance.

-> donc comme dit Christophe, il s'agit d'un sucre, mais d'un sucre en
morceaux, on a du solide derrière (une vrai instance) donc on peut faire
la même chose qu'avec une méthode, hors mis le fait d'utiliser une
variable privée (on peut toujours utiliser les accesseurs publiques).
donc on n'est en aucun cas obligé d'avoir des variables statiques.

D'ailleurs il y a peu de temps j'ai été obligé de migrer des méthodes
d'extensions vers des méthodes plus classique (pour l'occasion, soucis
de noms trop communs comme ton Add) et hors mis le fait de déplacer mon
code, de supprimer le premier argument (this)... et bien rien n'a changé :)

Note: en y regardant de plus près une méthode d'extension ne peut pas en
fait être une méthode statique d'une classe. Son écriture nous trompe
vraiment sur sa vrai nature.
--
Jérémy JEANSON
MCP
http://jeremy.blogdns.net

Bonjour Jérémy,

Je vois ce qu'est une méthode statique, mais j'avoue que je percevrai
mieux la portée de ton message une fois que j'aurai terminé mon progr amme.
_____________________________________________
Jérémy Jeanson a écrit, le 01/12/2008 08:48 :

Bonjour tout le monde,

Ok pour l'expression sucre syntaxique :) ,...

Mais par contre pas trop pour le côté static : Pourquoi?
1) oui on déclare une méthode statique dans une classe statique hor s de
la calsse à étandre.
2) le premier argmuent est une instance de la classe étandue :) et ou i
UNE instance.

-> donc comme dit Christophe, il s'agit d'un sucre, mais d'un sucre en
morceaux, on a du solide derrière (une vrai instance) donc on peut fa ire
la même chose qu'avec une méthode, hors mis le fait d'utiliser une
variable privée (on peut toujours utiliser les accesseurs publiques).
donc on n'est en aucun cas obligé d'avoir des variables statiques.

D'ailleurs il y a peu de temps j'ai été obligé de migrer des mé thodes
d'extensions vers des méthodes plus classique (pour l'occasion, souci s
de noms trop communs comme ton Add) et hors mis le fait de déplacer m on
code, de supprimer le premier argument (this)... et bien rien n'a chang é :)

Note: en y regardant de plus près une méthode d'extension ne peut p as en
fait être une méthode statique d'une classe. Son écriture nous tr ompe
vraiment sur sa vrai nature.

"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de groupe
de discussion : O6$Thl4UJHA.5268@TK2MSFTNGP04.phx.gbl...

Bonjour tout le monde,

Ok pour l'expression sucre syntaxique :) ,...

Mais par contre pas trop pour le côté static : Pourquoi?
1) oui on déclare une méthode statique dans une classe statique hors de la
calsse à étandre.
2) le premier argmuent est une instance de la classe étandue :) et oui UNE
instance.

La conséquence du coté static est que le système d'extension ne permet pas
de rajouter des membres, propriétés ou events à la classe qu'on souhaite
étendre.

Si on crée des nouveaux membres dans cette nouvelle classe, l'instance
"this" transmise en paramètre à la méthode d'extension ne permet pas d'y
accéder, puisqu'elle est du type de l'ancienne classe et non de celle qu'on
est en train de créer. La nouvelle méthode ne permet pas plus d'y accéder vu
qu'elle est statique (à moins de crée les nouveaux membres statiques).

En conclusion, les extensions de méthode ne permettent pas de créer des
choses qu'il était impossible de faire au préalable, mais fournit juste un
moyen d'écriture plus pratique (*comme si* il s'agissait d'une nouvelle
méthode de la classe qu'on extend alors qu'il n'en est rien).

C'est précisément ce qu'on a l'habitude de désigner par l'expression sucre
syntaxique :)

"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de groupe de
discussion : esqV2QvUJHA.1360@TK2MSFTNGP05.phx.gbl...

Au départ, j'avais compris qu'il s'agissait de convertir (cast) la liste
combinée déroulante en BindingList<string>.
Comme je me suis fait jeter à ce niveau-là (erreur CS0030), j'ai regardé
d'un peu plus près l'exemple fourni dans l'aide en ligne (pas avec un
BindingList<string> mais avec un BindingList<Part>). En fait, c'est un peu
plus sioux que ça, l'un doit agir sur l'autre, c'est bien ça ?

Hum, je suis pas sur de comprendre la question...

List<T> et BindingList<T> sont deux classes totalement distinctes, mais qui
implémentent toutes les deux IList<T> et/ou IEnumerable<T>.

Les items de la liste sont dans un IList (ou IEnumerable, je sais plus), qui
peut donc être concrètement un List comme un BindingList.

Lorsqu'on accède à la propriété Items de la liste déroulante, il doit
regarder si la propriété datasource est null, auquel cas il utilise une List
interne, qu'elle crée elle-même, ou la liste déroulante accède au conteneur
qui a été bindé dans le cas contraire.

Donc, l'interface doit non pas créer un nouvel élément dans la liste
combinée déroulante, mais dans la BindingList, et c'est celle-ci qui va le
répercuter dans la liste combinée déroulante.

J'ai le flemme de vérifier, mais il est probable que ça fasse la même chose
si tu ajoutes un élément à travers ma_liste_deroulante.Items.Add(...) : la
propriété Items sera redirigée de toute façon vers la BindingList.

Et la BindingList n'a pas d'interface propre, en dehors de la liste
déroulante qu'on va explicitement mettre à jour via le délégué.

Ai-je bien perçu l'esprit de la chose ?

La BindingList n'est qu'un conteneur. Elle n'a donc pas, en effet, de GUI(*)
qui lui soit propre.

(*) Attention au terme interface, qui désigne quelque chose de particulier
en c#. Je pense que tu voulais dire GUI lorsque tu as parlé d'interface.

Christophe Lephay a écrit, le 02/12/2008 17:49 :

"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de group e
de discussion : esqV2QvUJHA.1360@TK2MSFTNGP05.phx.gbl...

Au départ, j'avais compris qu'il s'agissait de convertir (cast) la
liste combinée déroulante en BindingList<string>.
Comme je me suis fait jeter à ce niveau-là (erreur CS0030), j'ai
regardé d'un peu plus près l'exemple fourni dans l'aide en ligne ( pas
avec un BindingList<string> mais avec un BindingList<Part>). En fait,
c'est un peu plus sioux que ça, l'un doit agir sur l'autre, c'est bi en
ça ?

Hum, je suis pas sur de comprendre la question...

List<T> et BindingList<T> sont deux classes totalement distinctes, mais
qui implémentent toutes les deux IList<T> et/ou IEnumerable<T>.

Les items de la liste sont dans un IList (ou IEnumerable, je sais plus) ,
qui peut donc être concrètement un List comme un BindingList.

Lorsqu'on accède à la propriété Items de la liste déroulante, il doit
regarder si la propriété datasource est null, auquel cas il utilise une
List interne, qu'elle crée elle-même, ou la liste déroulante accè de au
conteneur qui a été bindé dans le cas contraire.

Ah, il n'est pas impossible qu'il y ait une suite ...

Donc, l'interface doit non pas créer un nouvel élément dans la l iste
combinée déroulante, mais dans la BindingList, et c'est celle-ci q ui
va le répercuter dans la liste combinée déroulante.

J'ai le flemme de vérifier, mais il est probable que ça fasse la mê me
chose si tu ajoutes un élément à travers
ma_liste_deroulante.Items.Add(...) : la propriété Items sera rediri gée
de toute façon vers la BindingList.

Ah bon ? Tiens, ça me surprend, vu qu'à ce que j'ai imaginé je dé finis
l'action de la BindingList, mais rien au niveau de la liste déroulante.
J'ai peut-être oublié un truc, aussi.

Et la BindingList n'a pas d'interface propre, en dehors de la liste
déroulante qu'on va explicitement mettre à jour via le délégué .

Ai-je bien perçu l'esprit de la chose ?

La BindingList n'est qu'un conteneur. Elle n'a donc pas, en effet, de
GUI(*) qui lui soit propre.

(*) Attention au terme interface, qui désigne quelque chose de
particulier en c#. Je pense que tu voulais dire GUI lorsque tu as parlé
d'interface.

Ah oui, effectivement, j'ai réalisé quand je venais juste d'envoyer l e
message. Il y a plus d'un que le mot peut dérouter d'ailleurs.

Christophe Lephay a écrit, le 02/12/2008 17:49 :

J'ai le flemme de vérifier, mais il est probable que ça fasse la mê me
chose si tu ajoutes un élément à travers
ma_liste_deroulante.Items.Add(...) : la propriété Items sera rediri gée
de toute façon vers la BindingList.

Aïe, il semblerait qu'il y a un paquet de trucs qu'il est grand temps
que je révise.

Quand je vois

BindingList<string> ma_liste;
ma_liste = new BindingList<string>();

je me dis que pour ajouter un élément ça se passe comme ça :
string strNouv = ma_liste.AddNew();

d'autant que si je tente de mettre un argument je me fais jeter à ce su jet.

Problème : comme ça je me fais jeter aussi ;
Constructor on type System.string not found.

Bon, j'imagine qu'il faut chercher l'explication du côté du type de
BindingList : il s'agit d'une collection générique. Cela signifie-t-i l
que l'ajout ne sera possible qu'une fois que j'aurai implémenté le
constructeur et quelques bricoles comme la procédure d'ajout ?

Bonjour Gloops,

En lisant la MSDN j'ai constaté qu'il fallait autorisé l'ajout d'item
avant d'en ajouter :)

Donc dans ton cas:
BindingList<string> ma_liste = new BindingList<string>();
ma_liste.AllowNew = true;

En C# 3 tu peux aussi te permettre ça :
BindingList<string> ma_liste = new BindingList<string>() {
AllowNew = true };

// perso j'aime beaucoup :)


// et le Add
String strNouv = "ma string";
ma_liste.Add(strNouv);

--
Jérémy JEANSON
MCP
http://www.jjeanson.fr