Discussion :

[mrrenard]

Bonjour,

J'ai chercher de partout un tutorial qui explique quel composants, classes, utilisé pour faire du multithreading avec wpf.

Je n'ai rien trouver de potable. Rien qui explique bien comment faire pour interagir avec une interface wpf dans des threads séparés.

Est-ce que quelqu'un connait un site, un exemple ou un tutorial sur ce sujet?

Cordialement

[Thomas Lebrun]

Je te conseille de jeter un oeil sur ce qu'a fait Eric Vernié: http://msdn.microsoft.com/fr-fr/netf.../cc895446.aspx / http://www.microsoft.com/france/visi...0-ae7450baba0b

[mrrenard]

Merci beaucoup! C'est très explicite

[ikeas]

une info quand meme pour le multithreading
ne jamais oublier de mettre le isbackground de ton thread a true sinon si tu as oublié d'arreter ton thread avant de fermer ton appli, ton appli ne se ferme pas avec le isbackground a true elle se ferme et tue le thread

et important
ne jamais oublier de decoupler les messages avec un le application dispatcher ou le dispatcher de ta fenetre ca si tu met en place des message et du bionding sur l'inteface graphique y'a des chances que ca plante si c'est pas decouplé

[Marcolinho]

J'ai vu quelque chose qui m'intéresse !

et important
ne jamais oublier de decoupler les messages avec un le application dispatcher ou le dispatcher de ta fenetre ca si tu met en place des message et du bionding sur l'inteface graphique y'a des chances que ca plante si c'est pas decouplé

En fait je ne sais pas trop de quoi tu parles, mais depuis peu, j'ai cette erreur qui arrive (mais pas tout le temps :s) :

Le CLR n'a pas pu effectuer de transition du contexte COM 0x1fa838 au contexte COM 0x1fa9a8 pendant 60 secondes. Le thread qui possède le contexte/cloisonnement de destination est probablement en train d'attendre ou de traiter une opération très longue sans pompage des messages Windows. Cette situation a généralement des effets négatifs sur les performances et peut parfois entraîner le blocage de l'application ou une utilisation ininterrompue de la mémoire. Pour éviter ce problème, tous les threads STA (Single Threaded Apartment) doivent utiliser des primitives d'attente de pompage (par exemple CoWaitForMultipleHandles) et pomper de manière régulière les messages lors des opérations qui sont longues à s'exécuter.

Je me demande si c'est lié à ce que tu viens de décrire, et si oui, où est ce que je pourrais trouver plus d'informations ?
Merci beaucoup

[ikeas]

je ne sais pas, car en general quand tu as un probleme avec COM c'est que tu utilise des elements systeme mais plutot dans le systeme XP sur des composants en mode non manager mais bon

je te conseil quand mem de decoupler,
un petit exemple imaginons un thread
(je te fais le code en directe il y aura donc des problemes avec les majuscules)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
public class macclass
{
   public event eventhandler monevent;
   public void mathreadfocntion()
   {
      thread x = new thread(nes threadstart(toto));
      x.isbackgroung = true;
      x.start();
   }
   public void toto()
   {
      int i = 0;
      while((++i) < 20)
      {
         thread.sleep(1000); // attent une seconde
         if(monevent != null)
            monevent(this,eventargs.empty);
 
      }
   }

avec ce code la il peut y avoir un probleme de lancement de l'event vers une classe de ce type notamement quand tu as un element de binding dans les traitement du message ou simplement un acces a un element graphique

par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
maclass x = new maclasse();
x.monevent += new eventhandler(titi);
x.mathreadfonction();
 
public void titi(object sender, eventargs e)
{
   this.textbox1.text = "tata";
}

la ca ne focntionnera pas il faut decoupler les messages
et le mieux structurelement c'est de la faire dans le lancement du message dans la classe maclasse

avec un dispatcher sur application.current

si tu veux je mettrait cet exemple au propre et je le ferrais sous vs pour que ce soit plus simple (demain sans doute)