Discussion :

[giova_fr]

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 :

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

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

[GuruuMeditation]

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

[giova_fr]

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.

[Pol63]

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

[GuruuMeditation]

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!

[giova_fr]

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...

[Pol63]

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
ca peut servir pour bricoler ou pour des petites choses, mais c'est à éviter pour des gros morceaux