Thread et librairie

Version imprimable

Thread et librairie

Bonjour à tous,

Voulant créer organiser un client-serveur dans une librairie pour que ça soit portable pour de futur développements, j'ai crée une classe Client.

Cette classe fonctionne ou presque car j'ai un Thread d'écoute qui tourne pour vérifier si un message a été reçu. Lorsqu'il en trappe un, il lance un évènement (si il est défini).

Mon soucis est que je ne comprend pas trop comment résoudre mon problème inter-thread. Ma fenêtre crée un Client et s'abonne à l'évènement mais lorsque je déclenche l'évènement depuis mon Client pour le réceptionner dans la classe qui contient la fenêtre, ça coince. Mon but serais de faire comme on peut faire avec les composants standard, à savoir, je m'abonne puis je défini ce qui dois être fais.

Voici le code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 // Class client public delegate void ReceiveHandler(object sender, string text); public event ReceiveHandler ReceiceEventHandler; ... // Methode de connection _listener = new Thread(new ThreadStart(Receive)); _listener.Start(); ... // Methode Receive (du thread) if (message.Length != 0 && ReceiceEventHandler != null) { ReceiceEventHandler(this, message); } // Class de la fenetre (ça peut etre autre chose comme une console...) // Connection _client = new Client(Boite_Serveur.Text, Convert.ToInt32(Boite_Port.Text)); _client.ReceiceEventHandler += new Client.ReceiveHandler(_client_ReceiceEventHandler); ... void _client_ReceiceEventHandler(object sender, string text) { if (text.Contains("#liste")) { listeConnecte.Items.Clear(); string[] S_message = text.Split('|'); for (int i = 1; i < S_message.Length; i++) { listeConnecte.Items.Insert(listeConnecte.Items.Count, S_message[i]); } } ....
en faite, tout ce passe bien mais arrivé à la méthode "_client_ReceiceEventHandler", dès que j'utilise un élément de la fenêtre, ça explose. Pourtant, lorsque je m'abonne à des évènements dans des librairies ou autre par exemple, je n'ai pas ce problème...

On ne peut toucher à une composant visuel qu'à partir du thread qui l'a crée (en général, le thread principal). Vu ta description, ton code _client_ReceiveMachin s'exécuter dans un autre Thread donc boom.
Pour que ça marche il faut passer dans le thread principal avec Control.Invoke et ça ferai un truc genre

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
if (text.Contains("#liste"))
            {
                this.Invoke(new MethodInvoker(delegate{
                      listeConnecte.Items.Clear();
                      string[] S_message = text.Split('|');
                      for (int i = 1; i < S_message.Length; i++)
                      {
                          listeConnecte.Items.Insert(listeConnecte.Items.Count, S_message[i]);
                      }
                  }));
                }
            }

30/07/2009, 22h29
poussinphp

Merci mais malheureusement, je connaissais cette solution mais je cherchais à avoir un système plus "propre" :oops:. Disons que j'aimerais bien exporter cette petite librairie et tout englober dans un delegate avec invoke...

Il n'y a pas un moyen de rendre le coté en dehors de la librairie plus propre? à savoir, que la personne voulant utiliser la librairie n'ai pas à tout englober dans un delegate...?

En même temps, je pensais que c'étais la fenêtre abonné à l'évènement qui en étais le propriétaire (ou qu'il passaient l'un après l'autre...)
30/07/2009, 22h46
smyley

Citation:

Envoyé par poussinphp

Disons que j'aimerais bien exporter cette petite librairie et tout englober dans un delegate avec invoke...

C'est ça que tu appelles plus propre ?!

Normalement c'est un problème de conception. La lib ne doit pas avoir à accéder à l'interface et si la lib est multithread ou en tout cas n'exécute pas tout ce qu'il faut sur le thread principal, c'est à l'appelant de s'adapter. Tu aura tout le mal du monde à faire la transition de thread à l'intérieur de la lib car il faut toujours que tu aies accès à l'interface (pour que le this.Invoke fonctionne comme voulu) et du coup il faudrait envoyer l'interface à la lib ce qui est tout sauf propre.

Et quand on s'abonne à un évènement à partir d'un thread, l'évènement n'est pas lancé sur le thread dans lequel il a été inscrit, mais dans le thread qui a généré l'évènement.
30/07/2009, 22h59
poussinphp

Je me suis trompé... je voulais dire "et ne pas tout englober dans un delegate avec invoke" :oops:

Tu as raison, je devrais essayer de modifier ma conception mais pour cela, fraudais que je trouve une solution pour récupérer le message simplement et proprement dans ma form sans que ça gêne le reste... ;)

En tout cas, merci pour les réponses :ccool:
31/07/2009, 09h31
Guulh

Citation:

Envoyé par smyley

Et quand on s'abonne à un évènement à partir d'un thread, l'évènement n'est pas lancé sur le thread dans lequel il a été inscrit, mais dans le thread qui a généré l'évènement.

Il existe pourtant l'interface ISynchronizeInvoke,
qui permet à un objet de la business layer de lancer ses events sur le thread qui va bien. La DataTable doit probablement l'implémenter, puisqu'un ajout de données à une DataTable dans un thread métier ne fait pas péter une DataGridView.

Si tu crées un Component, et que tu le rajoutes à une form via designer, il est construit en lui filant en paramètre un IContainer, qui est le Container de la Form ; ce qui affecte la propriété "Site" du contrôle, qui est du type ISynchronizeInvoke.
31/07/2009, 11h51
smyley

Ce qui reviens donc à passer un composant de l'interface qui aura aussi une méthode Invoke qui pourra faire l'appel. Retour à la case départ.
Je ne crois pas que ce soit à la lib de se synchroniser mais à l'interface de placer les appels dans le bon thread ...
31/07/2009, 13h39
Guulh

Citation:

Envoyé par smyley

Ce qui reviens donc à passer un composant de l'interface qui aura aussi une méthode Invoke qui pourra faire l'appel. Retour à la case départ.
Je ne crois pas que ce soit à la lib de se synchroniser mais à l'interface de placer les appels dans le bon thread ...

Vu que de toutes façon, le composant métier M a une référence vers le composant graphique G, dès lors que G s'abonne à une méthode de C, il ne paraît pas choquant d'avoir en plus un référence explicite de G vers C. Via une interface, hein, on va pas spaghettiser le truc :)

Après, j'ai pu lire beaucoup de critiques concernant les choix de Microsoft vis à vis d'ADO.Net, puisque les designer vont par défaut mettre les DataTable et DataSet dans la form en elle-même, ce qui est pas top d'un point de vue séparation en couche.

Faudrait que je me penche un peu plus sur ces fameux Component, moi :aie: