Discussion :

[levalp]

Bonjour,
Je fais un programme dans lequel une fonction doit être avertie qu'une valeur a changé ou qu'un élément s'est ajouté dans une Liste.
J'ai regardé comment fonctionnent les Events en C# et je trouve cela assez compliqué. Y aurait-il un moyen plus simple ? J'essaie d'éviter une boucle infinie qui serait une solution pas très propre et qui consomme beaucoup de ressources, je pense.
Merci d'avance pour vos réponses.

[Bluedeep]

Euh ....

Qu'est ce qui ne te va pas dans les events ? C'est simple et "straightforward"
De plus, si tu veux monitorer une liste (si j'ai bien compris ton besoin) tu as deux moyens simples :

- utiliser une ObservableCollection (3.0, assembly WindowsBase)

- définir ta propre collection héritée de Collection<T> et overrider les méthodes InsertItem, RemoveItem, ClearItems etc ... pour déclencher tes évenements sur modification de la collection (plus très utile avec l'avénement de l'ObservableCollection).

Ne parlons même pas de ton histoire de boucle infinie, là ce n'est même plus du développement mais de la poésie toute pure.

[Guulh]

BindingList ! BindingList !

ou si tu bosses avec la base...

DataTable ! DataTable !

[Bluedeep]

BindingList ! BindingList !

Objectivement, je trouve l'ObservableCollection beaucoup plus simple à utiliser que les Bindings.

ou si tu bosses avec la base...

Pas obligatoirement, ça marche très bien sans.

[levalp]

Ne parlons même pas de ton histoire de boucle infinie, là ce n'est même plus du développement mais de la poésie toute pure.

Un pote vient de me dire qu'il programme toujours ce genre de truc avec une boucle infinie...
Enfin, je vais regarder les ObservableCollection, BindingList, et DataTable pour voir comment ca fonctionne.

[Guulh]

Objectivement, je trouve l'ObservableCollection beaucoup plus simple à utiliser que les Bindings.

Je n'en doute pas, et m'empresserai de l'essayer dès que je me lance dans le Fx 3.0 ou 3.5.

Pas obligatoirement, ça marche très bien sans.

Certes, mais une approche tout objet, préférant des objets typés à des tuples, est parfois plus adaptée. Les DataTable sont néanmoins très utile, je te l'accorde

[levalp]

Ne parlons même pas de ton histoire de boucle infinie, là ce n'est même plus du développement mais de la poésie toute pure.

Penses-tu qu'il faut à tout prix éviter les boucles infinies, même si on travaille avec plusieurs threads dans un même programme ? (un thread attendant le résultat d'un autre)

[Guulh]

Pour répondre en deux mots : la syntaxe de C# a été conçue pour faciliter la programmation à base d'événements, qui permettent à des classes de s'abonner à des événements (d'où le nom ) émis par d'autres classes. C'est TRES utilisé par le framework, notamment par les Windows Forms par exemple. Je te conseille de te documenter sur les mots clés "event", "delegate" du C#.

[levalp]

Pour répondre en deux mots : la syntaxe de C# a été conçue pour faciliter la programmation à base d'événements, qui permettent à des classes de s'abonner à des événements (d'où le nom ) émis par d'autres classes. C'est TRES utilisé par le framework, notamment par les Windows Forms par exemple. Je te conseille de te documenter sur les mots clés "event", "delegate" du C#.

Merci pour ta réponse. C'est ce que je vais faire.

[neilbgr]

Penses-tu qu'il faut à tout prix éviter les boucles infinies, même si on travaille avec plusieurs threads dans un même programme ? (un thread attendant le résultat d'un autre)

A mon avis, oui, il vaut mieux éviter... Et pour y remédier, il existe des classes pour se synchroniser entre threads, et cela ne prend pas de temps processeur. Je parle de AutoResetEvent, et ManualResetEvent.
A creuser !

[levalp]

A mon avis, oui, il vaut mieux éviter... Et pour y remédier, il existe des classes pour se synchroniser entre threads, et cela ne prend pas de temps processeur. Je parle de AutoResetEvent, et ManualResetEvent.
A creuser !

Je vais creuser.
Quelqu'un aurait un exemple de programme avec une ObservableAssembly ?
Il y en a un sur MSDN mais je n'arrive pas à le faire fonctionner.
Merci d'avance.

[Bluedeep]

Bonjour

Je n'en doute pas, et m'empresserai de l'essayer dès que je me lance dans le Fx 3.0 ou 3.5.

Il est utile de préciser que cette partie du 3.0 est une extension du System namespace qui n'implique absolument pas l'utilisation de WWF, WPF, WCF. Tu peux installer le 3.0 et te contenter de rajouter WindowsBase aux références de ton projet pour profiter de cette extension, sans te préoccuper des W*F.

Certes, mais une approche tout objet, préférant des objets typés à des tuples, est parfois plus adaptée. Les DataTable sont néanmoins très utile, je te l'accorde

Je partage entiérement ton point de vue, et sortie des classes de DAL, j'estime que, sauf exception, il n'y a pas lieu d'avoir des références au System.Data dans le reste de l'application.

[Bluedeep]

Penses-tu qu'il faut à tout prix éviter les boucles infinies, même si on travaille avec plusieurs threads dans un même programme ? (un thread attendant le résultat d'un autre)

Comme dit plus haut, il y a toute une panoplie d'objets pour synchroniser des threads ou ce que tu veux; dans ce cas utiliser une boucle infinie relève de (très) mauvaises pratiques de programmation.

[levalp]

Comme dit plus haut, il y a toute une panoplie d'objets pour synchroniser des threads ou ce que tu veux; dans ce cas utiliser une boucle infinie relève de (très) mauvaises pratiques de programmation.

OK, je vois ce que tu veux dire.

Je vais creuser.
Quelqu'un aurait un exemple de programme avec une ObservableAssembly ?
Il y en a un sur MSDN mais je n'arrive pas à le faire fonctionner.
Merci d'avance.

Je viens de me rendre compte que le ObservableAssembly relève du Framework 3. J'ai VS2005 et seulement le Framework 2 et je ne pourrai donc pas l'utiliser.

[SirJulio]

Pour le framework 2.0, tu peux alors utiliser une BindingList<>, voire meme créer la tienne (derive de CollectionBase<> avec une classe levant les events) si tes besoins sont plus simples qu'une BindingList<>

[levalp]

Pour le framework 2.0, tu peux alors utiliser une BindingList<>, voire meme créer la tienne (derive de CollectionBase<> avec une classe levant les events) si tes besoins sont plus simples qu'une BindingList<>

OK. Peut-on utiliser un wait avec un événement généré par une BindingList ?
(une fonction attend que la Bindinglist soit modifiée)

[Guulh]

OK. Peut-on utiliser un wait avec un événement généré par une BindingList ?
(une fonction attend que la Bindinglist soit modifiée)

Il n'y a pas à attendre. Je te conseille vraiment de te renseigner sur le système d'events de C#...
En deux mots : une classe Emetteur peut présenter un event. Toute autre classe Recepteur peut abonner une fonction à cet event ; cette fonction sera automatiquement appelée lorsque l'Emetteur déclenche son event.

Dans le cas qui t'intéresse, tu crées une BindingList, puis tu abonnes une de tes classes à l'événement ListChanged de cette BindingList.

Les event n'ont rien à voir avec les threads. Donc pas de wait.

[levalp]

Les event n'ont rien à voir avec les threads. Donc pas de wait.

OK, mais un thread peut contenir un wait, me trompe-je ?

[SirJulio]

OK, mais un thread peut contenir un wait, me trompe-je ?

Salut,

oui, bien sur (enfin un sleep(double) quoi), mais comme dit au dessus, il n'y a aucun rapport avec les events. Peut-tu preciser ce que tu cherches en parlant de ca :

"OK. Peut-on utiliser un wait avec un événement généré par une BindingList ?
(une fonction attend que la Bindinglist soit modifiée)"

Car ceci est la description meme d'un event (il se declenche sur une action precise).

[Guulh]

Tu ne te trompes pas. Mais si tu veux t'abonner via les event aux modifications d'une BindingList, tu n'as pas besoin ni de thread, ni de wait, ni de rien de compliqué