Voici quelques mois m'a =E9t=E9 montr=E9 comment lier un combobox =E0 un =
BindingList<String> pour faciliter la synchronisation entre le contr=F4le=
=20
et un fichier texte qui contient les donn=E9es.
Le lien se fait par l'instruction cmbFormats.DataSource =3D ma_liste, ce =
qui permet de mettre =E0 profil l'=E9v=E9nement ListChanged de ma_liste.
Aujourd'hui, j'aimerais faire la m=EAme chose avec une checkedListbox, et=
=20
je rencontre une difficult=E9 nouvelle : la checkedListbox n'a pas de=20
propri=E9t=E9 DataSource.
Elle a une propri=E9t=E9 DataBind, en revanche. On trouve des exemples po=
ur=20
lier le DataBind =E0 une base de donn=E9es via un DataTable, mais je dois=
=20
dire que pour lier le DataTable =E0 un fichier texte, c'est quelque chose=
=20
qu'il me semble bien avoir fait il y a un bon moment dans une base=20
Access, avec un pilote adapt=E9, mais est-ce raisonnable d'en chercher un=
=20
pour VS 2005 ?
C'est vrai que dans une checkedListbox, chaque ligne a deux champs, un=20
texte et un bool=E9en, mais =E0 la limite on peut donner une valeur par=20
d=E9faut au bool=E9en.
Est-ce qu'on peut mettre en =9Cuvre le m=EAme principe, avoir un objet =E0=
=20
mettre =E0 jour dont la modification d=E9clenche un =E9v=E9nement o=F9 on=
peut=20
mettre =E0 jour le fichier pendant que le contr=F4le est mis =E0 jour du =
m=EAme=20
coup ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jérémy Jeanson
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
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
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
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 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 :)
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 :)
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
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
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
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 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 ?
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
> 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'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'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)
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.
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.
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.