Est-ce qu'un ComboBox (ou un ListBox, j'imagine que la r=E9ponse est la=20
m=EAme) d=E9clenche un =E9v=E9nement lorsqu'on lui ajoute un =E9l=E9ment =
(Items.Add)=20
ou qu'on en retire un (Items.Remove), ou doit-on g=E9rer soi-m=EAme un=20
delegate ?
Dans le premier cas je suis pass=E9 devant sans voir ...
Donc oui il serrait conseillé de faire remonter les informations de modifications par tes propres moyens. -- Jérémy JEANSON MCP http://jeremy.blogdns.net
Non cela n'existe pas, désolé :(
Donc oui il serrait conseillé de faire remonter les informations de
modifications par tes propres moyens.
--
Jérémy JEANSON
MCP
http://jeremy.blogdns.net
Donc oui il serrait conseillé de faire remonter les informations de modifications par tes propres moyens. -- Jérémy JEANSON MCP http://jeremy.blogdns.net
Gloops
Jérémy Jeanson a écrit, le 18/11/2008 09:36 :
Non cela n'existe pas, désolé :(
Donc oui il serrait conseillé de faire remonter les informations de modifications par tes propres moyens.
OK, merci.
C'est quand même plus agréable d'être sûr qu'on n'est pas en trai n de travailler pour rien :)
Jérémy Jeanson a écrit, le 18/11/2008 09:36 :
Non cela n'existe pas, désolé :(
Donc oui il serrait conseillé de faire remonter les informations de
modifications par tes propres moyens.
OK, merci.
C'est quand même plus agréable d'être sûr qu'on n'est pas en trai n de
travailler pour rien :)
Donc oui il serrait conseillé de faire remonter les informations de modifications par tes propres moyens.
OK, merci.
C'est quand même plus agréable d'être sûr qu'on n'est pas en trai n de travailler pour rien :)
Christophe Lephay
"Gloops" a écrit dans le message de groupe de discussion :
Bonjour tout le monde,
Est-ce qu'un ComboBox (ou un ListBox, j'imagine que la réponse est la même) déclenche un événement lorsqu'on lui ajoute un élément (Items.Add) ou qu'on en retire un (Items.Remove), ou doit-on gérer soi-même un delegate ?
Dans le premier cas je suis passé devant sans voir ...
Tu peux gérer le problème via un DataBinding, en bindant la listbox à une BindingList.
La BindingList se chargera alors des notifications...
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de groupe de
discussion : OnqQDZVSJHA.5344@TK2MSFTNGP06.phx.gbl...
Bonjour tout le monde,
Est-ce qu'un ComboBox (ou un ListBox, j'imagine que la réponse est la
même) déclenche un événement lorsqu'on lui ajoute un élément (Items.Add)
ou qu'on en retire un (Items.Remove), ou doit-on gérer soi-même un
delegate ?
Dans le premier cas je suis passé devant sans voir ...
Tu peux gérer le problème via un DataBinding, en bindant la listbox à une
BindingList.
La BindingList se chargera alors des notifications...
"Gloops" a écrit dans le message de groupe de discussion :
Bonjour tout le monde,
Est-ce qu'un ComboBox (ou un ListBox, j'imagine que la réponse est la même) déclenche un événement lorsqu'on lui ajoute un élément (Items.Add) ou qu'on en retire un (Items.Remove), ou doit-on gérer soi-même un delegate ?
Dans le premier cas je suis passé devant sans voir ...
Tu peux gérer le problème via un DataBinding, en bindant la listbox à une BindingList.
La BindingList se chargera alors des notifications...
Gloops
Christophe Lephay a écrit, le 25/11/2008 19:40 : > Tu peux gérer le problème via un DataBinding, en bindant la listb ox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je vais m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les valeu rs dans un fichier texte, qui serait créé au premier enregistrement de données si il n'existe pas -et que l'utilisateur peut aussi créer ave c le bloc-notes si il préfère. A ce stade (pas encore lu la doc) je ne me rends pas encore compte si le fichier texte est adapté à l'exploitati on d'une BindingList.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis ren du compte que c'est adapté à un traitement appelé depuis une autre applicatio n : hors sujet, la fonction de mise à jour des données pouvant très bie n se trouver dans le code du même formulaire. L'appel est alors tout simple, juste placer le nom de la fonction à chaque endroit où son exécutio n est requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ça p eut donner quelque chose de plus élégant me semble-t-il.
Christophe Lephay a écrit, le 25/11/2008 19:40 :
> Tu peux gérer le problème via un DataBinding, en bindant la listb ox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je vais
m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les valeu rs
dans un fichier texte, qui serait créé au premier enregistrement de
données si il n'existe pas -et que l'utilisateur peut aussi créer ave c
le bloc-notes si il préfère. A ce stade (pas encore lu la doc) je ne me
rends pas encore compte si le fichier texte est adapté à l'exploitati on
d'une BindingList.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis ren du compte
que c'est adapté à un traitement appelé depuis une autre applicatio n :
hors sujet, la fonction de mise à jour des données pouvant très bie n se
trouver dans le code du même formulaire. L'appel est alors tout simple,
juste placer le nom de la fonction à chaque endroit où son exécutio n est
requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ça p eut
donner quelque chose de plus élégant me semble-t-il.
Christophe Lephay a écrit, le 25/11/2008 19:40 : > Tu peux gérer le problème via un DataBinding, en bindant la listb ox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je vais m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les valeu rs dans un fichier texte, qui serait créé au premier enregistrement de données si il n'existe pas -et que l'utilisateur peut aussi créer ave c le bloc-notes si il préfère. A ce stade (pas encore lu la doc) je ne me rends pas encore compte si le fichier texte est adapté à l'exploitati on d'une BindingList.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis ren du compte que c'est adapté à un traitement appelé depuis une autre applicatio n : hors sujet, la fonction de mise à jour des données pouvant très bie n se trouver dans le code du même formulaire. L'appel est alors tout simple, juste placer le nom de la fonction à chaque endroit où son exécutio n est requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ça p eut donner quelque chose de plus élégant me semble-t-il.
Gloops
Gloops a écrit, le 26/11/2008 11:06 :
à chaque endroit où son exécution est requis.
Youps, ah ben pour justifier l'orthographe, là, va falloir être soupl e ...
Gloops a écrit, le 26/11/2008 11:06 :
à chaque endroit où son exécution est
requis.
Youps, ah ben pour justifier l'orthographe, là, va falloir être soupl e ...
Youps, ah ben pour justifier l'orthographe, là, va falloir être soupl e ...
Jérémy Jeanson
On a vu pire, ne t'en fais pas.
Mode hors sujet : Tu peux aussi envisager que cela te fait une lettre de plus pour ta réserve personnelle. :) -- Jérémy JEANSON MCP http://jeremy.blogdns.net
On a vu pire, ne t'en fais pas.
Mode hors sujet :
Tu peux aussi envisager que cela te fait une lettre de plus pour ta
réserve personnelle. :)
--
Jérémy JEANSON
MCP
http://jeremy.blogdns.net
Mode hors sujet : Tu peux aussi envisager que cela te fait une lettre de plus pour ta réserve personnelle. :) -- Jérémy JEANSON MCP http://jeremy.blogdns.net
Jérémy Jeanson
Finalement, à vouloir joué au hors sujet, je crois que je viens de faire la pire phare qui soit.
> Mode hors sujet : > Tu peux aussi envisager que cela te fait une lettre de plus pour ta > > réserve personnelle.
-- Jérémy JEANSON MCP http://jeremy.blogdns.net
Finalement, à vouloir joué au hors sujet, je crois que je viens de faire
la pire phare qui soit.
> Mode hors sujet :
> Tu peux aussi envisager que cela te fait une lettre de plus pour ta >
> réserve personnelle.
Pardon pour ces égarements. -- Jérémy JEANSON MCP http://jeremy.blogdns.net
Christophe Lephay
"Gloops" a écrit dans le message de groupe de discussion : #
Christophe Lephay a écrit, le 25/11/2008 19:40 : > Tu peux gérer le problème via un DataBinding, en bindant la listbox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je vais m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les valeurs dans un fichier texte, qui serait créé au premier enregistrement de données si il n'existe pas -et que l'utilisateur peut aussi créer avec le bloc-notes si il préfère. A ce stade (pas encore lu la doc) je ne me rends pas encore compte si le fichier texte est adapté à l'exploitation d'une BindingList.
Un fichier texte peut être vu comme une simple liste de ligne de texte, donc il ne devrait pas y avoir de problème.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis rendu compte que c'est adapté à un traitement appelé depuis une autre application : hors sujet, la fonction de mise à jour des données pouvant très bien se trouver dans le code du même formulaire. L'appel est alors tout simple, juste placer le nom de la fonction à chaque endroit où son exécution est requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ça peut donner quelque chose de plus élégant me semble-t-il.
A noter que la bindinglist prend en charge les notifications sur les ajouts et les suppressions d'éléments, mais que la modification d'éléments existants doit être notifiée par les éléments eux-mêmes (qui doivent donc implémenter INotifyPropertyChanged). Du coup, si tu veux seulement des notifications en cas d'ajouts ou suppressions, c'est assez facile, mais ça peut être plus complexe si tu veux gérer aussi les notifications de modification.
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de groupe de
discussion : #nLsz66TJHA.3952@TK2MSFTNGP06.phx.gbl...
Christophe Lephay a écrit, le 25/11/2008 19:40 :
> Tu peux gérer le problème via un DataBinding, en bindant la listbox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je vais
m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les valeurs
dans un fichier texte, qui serait créé au premier enregistrement de
données si il n'existe pas -et que l'utilisateur peut aussi créer avec le
bloc-notes si il préfère. A ce stade (pas encore lu la doc) je ne me rends
pas encore compte si le fichier texte est adapté à l'exploitation d'une
BindingList.
Un fichier texte peut être vu comme une simple liste de ligne de texte, donc
il ne devrait pas y avoir de problème.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis rendu compte
que c'est adapté à un traitement appelé depuis une autre application :
hors sujet, la fonction de mise à jour des données pouvant très bien se
trouver dans le code du même formulaire. L'appel est alors tout simple,
juste placer le nom de la fonction à chaque endroit où son exécution est
requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ça peut
donner quelque chose de plus élégant me semble-t-il.
A noter que la bindinglist prend en charge les notifications sur les ajouts
et les suppressions d'éléments, mais que la modification d'éléments
existants doit être notifiée par les éléments eux-mêmes (qui doivent donc
implémenter INotifyPropertyChanged). Du coup, si tu veux seulement des
notifications en cas d'ajouts ou suppressions, c'est assez facile, mais ça
peut être plus complexe si tu veux gérer aussi les notifications de
modification.
"Gloops" a écrit dans le message de groupe de discussion : #
Christophe Lephay a écrit, le 25/11/2008 19:40 : > Tu peux gérer le problème via un DataBinding, en bindant la listbox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je vais m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les valeurs dans un fichier texte, qui serait créé au premier enregistrement de données si il n'existe pas -et que l'utilisateur peut aussi créer avec le bloc-notes si il préfère. A ce stade (pas encore lu la doc) je ne me rends pas encore compte si le fichier texte est adapté à l'exploitation d'une BindingList.
Un fichier texte peut être vu comme une simple liste de ligne de texte, donc il ne devrait pas y avoir de problème.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis rendu compte que c'est adapté à un traitement appelé depuis une autre application : hors sujet, la fonction de mise à jour des données pouvant très bien se trouver dans le code du même formulaire. L'appel est alors tout simple, juste placer le nom de la fonction à chaque endroit où son exécution est requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ça peut donner quelque chose de plus élégant me semble-t-il.
A noter que la bindinglist prend en charge les notifications sur les ajouts et les suppressions d'éléments, mais que la modification d'éléments existants doit être notifiée par les éléments eux-mêmes (qui doivent donc implémenter INotifyPropertyChanged). Du coup, si tu veux seulement des notifications en cas d'ajouts ou suppressions, c'est assez facile, mais ça peut être plus complexe si tu veux gérer aussi les notifications de modification.
Gloops
A ce qu'il m'a semblé, il faudra utiliser un objet d'accès aux donné es ... de type objet.
Donc, implémenter du code.
Plus élégant, mais pas forcément plus compatible avec le poil dans la main.
________________________________________________ Christophe Lephay a écrit, le 26/11/2008 13:57 :
"Gloops" a écrit dans le message de group e de discussion : #
Christophe Lephay a écrit, le 25/11/2008 19:40 : > Tu peux gérer le problème via un DataBinding, en bindant la lis tbox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je va is m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les valeurs dans un fichier texte, qui serait créé au premier enregistrement de données si il n'existe pas -et que l'utilisateur peut aussi créer avec le bloc-notes si il préfère. A ce stade (p as encore lu la doc) je ne me rends pas encore compte si le fichier texte est adapté à l'exploitation d'une BindingList.
Un fichier texte peut être vu comme une simple liste de ligne de text e, donc il ne devrait pas y avoir de problème.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis rendu compte que c'est adapté à un traitement appelé depuis une autre application : hors sujet, la fonction de mise à jour des données pouvant très bien se trouver dans le code du même formulaire. L'ap pel est alors tout simple, juste placer le nom de la fonction à chaque endroit où son exécution est requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ç a peut donner quelque chose de plus élégant me semble-t-il.
A noter que la bindinglist prend en charge les notifications sur les ajouts et les suppressions d'éléments, mais que la modification d'éléments existants doit être notifiée par les éléments eu x-mêmes (qui doivent donc implémenter INotifyPropertyChanged). Du coup, si tu veux seulement des notifications en cas d'ajouts ou suppressions, c'est asse z facile, mais ça peut être plus complexe si tu veux gérer aussi le s notifications de modification.
A ce qu'il m'a semblé, il faudra utiliser un objet d'accès aux donné es
... de type objet.
Donc, implémenter du code.
Plus élégant, mais pas forcément plus compatible avec le poil dans la main.
________________________________________________
Christophe Lephay a écrit, le 26/11/2008 13:57 :
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de group e
de discussion : #nLsz66TJHA.3952@TK2MSFTNGP06.phx.gbl...
Christophe Lephay a écrit, le 25/11/2008 19:40 :
> Tu peux gérer le problème via un DataBinding, en bindant la lis tbox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je va is
m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les
valeurs dans un fichier texte, qui serait créé au premier
enregistrement de données si il n'existe pas -et que l'utilisateur
peut aussi créer avec le bloc-notes si il préfère. A ce stade (p as
encore lu la doc) je ne me rends pas encore compte si le fichier texte
est adapté à l'exploitation d'une BindingList.
Un fichier texte peut être vu comme une simple liste de ligne de text e,
donc il ne devrait pas y avoir de problème.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis rendu
compte que c'est adapté à un traitement appelé depuis une autre
application : hors sujet, la fonction de mise à jour des données
pouvant très bien se trouver dans le code du même formulaire. L'ap pel
est alors tout simple, juste placer le nom de la fonction à chaque
endroit où son exécution est requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ç a peut
donner quelque chose de plus élégant me semble-t-il.
A noter que la bindinglist prend en charge les notifications sur les
ajouts et les suppressions d'éléments, mais que la modification
d'éléments existants doit être notifiée par les éléments eu x-mêmes (qui
doivent donc implémenter INotifyPropertyChanged). Du coup, si tu veux
seulement des notifications en cas d'ajouts ou suppressions, c'est asse z
facile, mais ça peut être plus complexe si tu veux gérer aussi le s
notifications de modification.
A ce qu'il m'a semblé, il faudra utiliser un objet d'accès aux donné es ... de type objet.
Donc, implémenter du code.
Plus élégant, mais pas forcément plus compatible avec le poil dans la main.
________________________________________________ Christophe Lephay a écrit, le 26/11/2008 13:57 :
"Gloops" a écrit dans le message de group e de discussion : #
Christophe Lephay a écrit, le 25/11/2008 19:40 : > Tu peux gérer le problème via un DataBinding, en bindant la lis tbox à
une BindingList.
La BindingList se chargera alors des notifications...
Effectivement ça paraît être une piste intéressante, que je va is m'empresser d'étudier.
Pour simplifier le déploiement, j'avais imaginé enregistrer les valeurs dans un fichier texte, qui serait créé au premier enregistrement de données si il n'existe pas -et que l'utilisateur peut aussi créer avec le bloc-notes si il préfère. A ce stade (p as encore lu la doc) je ne me rends pas encore compte si le fichier texte est adapté à l'exploitation d'une BindingList.
Un fichier texte peut être vu comme une simple liste de ligne de text e, donc il ne devrait pas y avoir de problème.
En tout cas merci pour cette idée.
Depuis l'autre jour j'ai révisé les délégués, et je me suis rendu compte que c'est adapté à un traitement appelé depuis une autre application : hors sujet, la fonction de mise à jour des données pouvant très bien se trouver dans le code du même formulaire. L'ap pel est alors tout simple, juste placer le nom de la fonction à chaque endroit où son exécution est requis.
Je vais me mettre à jour sur les BindingList, si ça s'applique ç a peut donner quelque chose de plus élégant me semble-t-il.
A noter que la bindinglist prend en charge les notifications sur les ajouts et les suppressions d'éléments, mais que la modification d'éléments existants doit être notifiée par les éléments eu x-mêmes (qui doivent donc implémenter INotifyPropertyChanged). Du coup, si tu veux seulement des notifications en cas d'ajouts ou suppressions, c'est asse z facile, mais ça peut être plus complexe si tu veux gérer aussi le s notifications de modification.
