Binding entre checkedListBox et fichier texte

Le
Gloops
Bonjour tout le monde,

Voici quelques mois m'a été montré comment lier un combobox à un =

BindingList<String> pour faciliter la synchronisation entre le contrôle=

et un fichier texte qui contient les données.

Le lien se fait par l'instruction cmbFormats.DataSource = ma_liste, ce =

qui permet de mettre à profil l'événement ListChanged de ma_liste.


Aujourd'hui, j'aimerais faire la même chose avec une checkedListbox, et=

je rencontre une difficulté nouvelle : la checkedListbox n'a pas de
propriété DataSource.

Elle a une propriété DataBind, en revanche. On trouve des exemples po=
ur
lier le DataBind à une base de données via un DataTable, mais je dois=

dire que pour lier le DataTable à un fichier texte, c'est quelque chose=

qu'il me semble bien avoir fait il y a un bon moment dans une base
Access, avec un pilote adapté, mais est-ce raisonnable d'en chercher un=

pour VS 2005 ?

C'est vrai que dans une checkedListbox, chaque ligne a deux champs, un
texte et un booléen, mais à la limite on peut donner une valeur par
défaut au booléen.

Est-ce qu'on peut mettre en œuvre le même principe, avoir un objet à=

mettre à jour dont la modification déclenche un événement où on=
peut
mettre à jour le fichier pendant que le contrôle est mis à jour du =
même
coup ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jérémy Jeanson
Le #19324351
Bonjour Gloops,

Pour tenter de répondre clairement et dans l'ordre.

Tu te poses des questions au sujet de l'utiliter de faire une recherche
pour VS 2005... En fait ton code serra forcémetn en .net2 et vu que
c'est la base de 3.0 et 3.5, ton code fonctionnera aussi dans VS2008.

Ensuite pour ce qui est de construire un objet qui va gérer tes données
en faisant le lien entre ton control et un fichier txt. Il n'y a pas de
raison que ce soit impossible. Je crois qu'on en a déjà parlé à l'époque
où la BindingLis<> t'avais été proposée.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Gloops
Le #19330441
Jérémy Jeanson a écrit, le 13/05/2009 12:32 :
Bonjour Gloops,



Bonjour Jérémy


Pour tenter de répondre clairement et dans l'ordre.

Tu te poses des questions au sujet de l'utiliter de faire une recherche
pour VS 2005... En fait ton code serra forcémetn en .net2 et vu que
c'est la base de 3.0 et 3.5, ton code fonctionnera aussi dans VS2008.



En fait, la recherche portait sur un pilote de données texte.
Dans mon programme j'ai lu le fichier en TextStream, comme ça ça roul e
tout seul. Il y a un bout de temps que j'ai fait ça, mais il me semble
qu'Access sait importer un fichier texte avec un pilote adapté. L'idé e
serait que si on ajoute du texte dans le fichier il apparaît
automatiquement dans le contrôle (je n'ai plus Access sous la main,
peut-être que j'enjolive).

C'est vrai que concrètement j'ai obtenu ça comme résultat en mode
TextStream, mais je me demandais si ça pouvait rimer à quelque chose,
sous Visual Studio, de définir un DataTable sur un fichier texte, et de
l'alimenter avec un DataAdapter, ou si à force de couper les cheveux en
quatre dans le sens de la longueur je vais finir par en couper un de
travers.



Ensuite pour ce qui est de construire un objet qui va gérer tes donné es
en faisant le lien entre ton control et un fichier txt. Il n'y a pas de
raison que ce soit impossible. Je crois qu'on en a déjà parlé à l'époque
où la BindingLis<> t'avais été proposée.



Je suis allé voir, il m'a semblé que le principe consistait à
initialiser la propriété DataSource du contrôle pour lui donner com me
valeur la BindingList<String>. C'est pour ça que l'absence de proprié té
DataSource sur le contrôle checkedListbox m'a un peu dérouté.

Il est vrai, comme je laisse entendre dans l'autre fil, que j'ai obtenu
le résultat en répétant les appels aux divers endroits où ils son t
souhaitables. Du coup pour la suppression d'une ligne, je crée un
nouveau fichier, et je recopie ligne par ligne sauf celle que je veux
supprimer, il ne reste plus à la fin qu'à supprimer l'ancien fichier et
donner son nom au fichier temporaire. Et puis, je vide le contrôle et j e
le remplis de nouveau en relisant le fichier.

Bon alors tu dis qu'on peut faire mieux, mais j'avoue que là je suis un
peu comme l'alcoolique qui fait tourner sa clef tout autour de la
serrure, à part que je fais peut-être moins de bruit :)
Jérémy Jeanson
Le #19330981
Bonjour Gloops,

Pour palier à un "pilote" dont tu serrais tributaire tu peux très bien
mettre en place un dispositif basé sur le FileSystemWatcher
http://msdn.microsoft.com/fr-fr/library/system.io.filesystemwatcher.aspx

C'est un control très pratique qui peut te servir à surveiller ce qui se
passe sur un fichier (ou répertoire) et donc lorsqu'une modification
survient mettre à jour ton interface. C'est relativement simple et la
prise ne main se fait très très vite ;) .

Pour ce qui est du stockage de données pour éviter les prise de tête et
garder l'aspect métier de tes objet et s'afranchire du stockage il y a
le XmlSerializer (en gros tu sérialise tes objets en XML pour écrire et
tu déserialises pour lire... cela se fait presque tout seul et il faut
vraiment avoir des cas très particuliers pour que cela ne fonctionne pas).

En gros avec XmlSerializer et FileSystemWatcher tu peux avoir une
solution peu contraignante, après, c'est à toi de voir comment tu veux
agencer tout ce petit monde pour que ce soit utilisé lors des
modifications de ton interface.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Gloops
Le #19331771
Jérémy Jeanson a écrit, le 14/05/2009 08:33 :
Bonjour Gloops,

Pour palier à un "pilote" dont tu serrais tributaire tu peux très b ien
mettre en place un dispositif basé sur le FileSystemWatcher
http://msdn.microsoft.com/fr-fr/library/system.io.filesystemwatcher.asp x

C'est un control très pratique qui peut te servir à surveiller ce q ui se
passe sur un fichier (ou répertoire) et donc lorsqu'une modification
survient mettre à jour ton interface. C'est relativement simple et la
prise ne main se fait très très vite ;) .



J'ai bien remarqué ce nom de contrôle dans la boîte à outils.
Bon alors il permet de savoir qu'il y a eu un changement sur le fichier,
et ensuite ... on ouvre le StreamReader ? ou on désérialise ...


Pour ce qui est du stockage de données pour éviter les prise de tê te et
garder l'aspect métier de tes objet et s'afranchire du stockage il y a
le XmlSerializer (en gros tu sérialise tes objets en XML pour écrir e et
tu déserialises pour lire... cela se fait presque tout seul et il fau t
vraiment avoir des cas très particuliers pour que cela ne fonctionne pas).



D'ailleurs, dans un autre projet je suis en train de travailler sur la
sérialisation d'un treeview, intéressant.
ça permet par exemple d'illustrer une question dans un newsgroup avec l e
contenu d'un treeview.

En gros avec XmlSerializer et FileSystemWatcher tu peux avoir une
solution peu contraignante, après, c'est à toi de voir comment tu v eux
agencer tout ce petit monde pour que ce soit utilisé lors des
modifications de ton interface.



C'est-à-dire que là maintenant ça commence à tourner assez propre ment,
en fait c'est surtout pour une question de style de programmation,
j'avais l'impression que c'était plus élégant d'avoir un contrôle ou un
Binding associé qui appelle un délégué (comme j'avais fait pour l es
formats de numéros de téléphones, mais avec un combobox) plutôt q ue de
répéter l'appel d'une procédure à plusieurs endroits dans le prog ramme.

Et au demeurant, s'agissant de chemins de répertoires, les seules
modifications qu'on peut avoir sont des ajouts et des suppressions. J'ai
appelé la mise à jour du contrôle dans le code du bouton d'ajout
(bientôt des deux boutons d'ajout en fait) et dans le code du bouton de
suppression, ainsi que bien entendu dans l'ouverture du formulaire.
Finalement, je ferais ça aussi si la mise à jour se faisait par
désérialisation, me semble-t-il. C'est juste le code de mise à jour qui
serait différent, mais pas la façon de l'appeler. Ou je me trompe ?
Jérémy Jeanson
Le #19331891
> J'ai bien remarqué ce nom de contrôle dans la boîte à outils.


> Bon alors il permet de savoir qu'il y a eu un changement sur le
> fichier, et ensuite ... on ouvre le StreamReader ? ou on désérialise ...

Oui tu lis ton fichier... enfin c'est ce qu'il me semble qu'il faudrait
faire (mais bien penser à stopper le watcher au moment où tu écris, si
non tu vas lire, écrire en boucle).

> C'est-à-dire que là maintenant ça commence à tourner assez proprement,
> en fait c'est surtout pour une question de style de programmation,
> j'avais l'impression que c'était plus élégant d'avoir un contrôle ou un
> Binding associé qui appelle un délégué (comme j'avais fait pour les
> formats de numéros de téléphones, mais avec un combobox) plutôt que de
> répéter l'appel d'une procédure à plusieurs endroits dans le programme.

Tout à fait d'accord, les delegués sont plus propres et plus facile à
maintenanire (et oui il faut aussi penser à ce que va devenir le code
dans le temps, et avec un gestion propre c'est plus simple d'anticiper).

Pour le reste, je pense que tu as raison. Ce sont les quelques petites
différences aux niveaux des mises à jours qui serraient différente et en
aucun cas les appels (en gros un petit mécanisme de couches avec un
fournisseur de données maison)

--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Gloops
Le #19332031
Jérémy Jeanson a écrit, le 14/05/2009 10:53 :
Pour le reste, je pense que tu as raison. Ce sont les quelques petites
différences aux niveaux des mises à jours qui serraient différent e et en
aucun cas les appels (en gros un petit mécanisme de couches avec un
fournisseur de données maison)




C'est ce qu'il m'avait semblé.
Or, dans le but, ma question portait sur les appels ...
Et comme la CheckedListbox n'a pas de propriété DataSource, ce n'est pas
simple de transposer ce qui avait été fait avec les formats de numé ros
de téléphone.

Bon, je crois que je vais laisser comme c'est alors.
Merci.
Publicité
Poster une réponse
Anonyme