attendre fin d'un thread sans bloquer le main thread

Bonjour.

Dans mon thread principal, il y a une pompe à message qui gere ma fenetre principale.

Je suis dans ce thread, et lance un second thread qui effectue un travail assez long. Ce second thread etant pour ne pas figer ma fenetre principale...

Ce que je voudrait faire :
bloquer la methode qui a lancé ce 2nd thread, sans pour autant figer ma pompe à message.

Existe t'il un moyen propre, autre que le code ci dessous pour y parvenir?

Code:

---

1 2 3 4 5

do { Thread.Sleep(1); }while(thread.IsAlive); //Bidouille pour bloquer le block en cours sans freeze de la pompe à message

---

Essaye plutôt avec un BackgroundWorker. C'est plus facile à utiliser, et il y a un évènement lorsque le travail est fini.

C'est ce que j'envisage en effet, mais je me demandais si il n'y avait pas une solution pour rester dans la methode qui lance le thread plutot que basculer dans une callback...

J'avous m'y perdre un peu sur le fonctionnement de la pompe à message, il ne faut pas la bloquer, mais en meme temps quand une methode du main thread s'execute on est cencé la bloquer... c'est un paradoxe que je n'arrive pas à saisir.

une méthode sur le main thread ne doit tout simplement pas durer plusieurs de quelques centaines de millisecondes pour être tranquille (et ne pas embêter l'utilisateur)

si tu veux tricher, tu peux utiliser system.windows.forms.application.doevents dans ta boucle, qui a pour effet de traiter les évènements en attente avant de revenir à la ligne suivante de l'appel à doevents
ca ne fige donc pas l'interface tout en permettant de continuer une méthode après une attente

Sinon, si tu es courageux, tu peux essayer avec le Async Framework (http://msdn.microsoft.com/fr-fr/vstudio/async) Il y a une licence Go-Live. C'est toujours expérimental. Mais ça simplifie tellement la vie!

Juste un mot pour vous remercier de vos réponses.

Apres reflexion, je vais utiliser le background worker que je vais coupler à une pseudo FSM. beaucoup de cas de figure etant possibles, à chaque fois avec le besoin de lancer un thread différent (un thread à la fois en plus du principale); ils feront des invokes sur ma form au besoin...

Merci pour l'astuce de application.doevents ca me servira un de ces quatres, mais comme je m'attaque à un gros morceau, je crains des effets de bord.

Quand à Async Framework j'utilise VS2008 Framework 3.5 donc...

Citation:

---

Envoyé par giova_fr

Merci pour l'astuce de application.doevents ca me servira un de ces quatres, mais comme je m'attaque à un gros morceau, je crains des effets de bord.

---

tu as bien raison, DoEvents sous vb6 avait en effet des effets de bord, genre cliquer pour fermer le form traité dans le laps de temps du doevents, une fois revenu dans la méthode on se retrove à lire des variables détruites :aie:
ca peut servir pour bricoler ou pour des petites choses, mais c'est à éviter pour des gros morceaux

DoEvents n'est pas une solution. Cette méthode ne devrait même pas exister, elle est là uniquement pour faciliter la migration VB vers VB.NET (même si pour moi, ce n'est toujours pas une bonne raison ^^).

Effectivement la solution est soit d'utiliser un callback, soit un backgroundworker.

Juste pour essayer de enfin comprendre....
la pompe à messages s'execute dans le main thread non?
qu'est ce qui la "cadence"?
J'ai du mal a imaginer que sans 2eme thread, on puisse la lire cycliquement...
d'un autre coté pour ne pas avoir d'errreur crossthread, les messages qu'elle interprete doivent etre executé dans mon main thread.