Discussion :

[Vonziz]

Bonjour,

Je me heurte à un problème de threading et je souhaiterais vous exposer ma problématique.

Lors d'un traitement lourd, je tente d'afficher dans un thread parallèle, une fenêtre d'attente dynamique. Voici ma classe :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Windows.Forms;
using System.Drawing;
 
namespace Test.Tools
{
    public class WaitDialogThread
    {
        Thread waitDialogThread;
        string textToDiplay;
        Point location;
 
        public WaitDialogThread(string text, Point loc)
        {
            textToDiplay = text;
            location = loc;
        }
 
        public void Start()
        {
            waitDialogThread = new Thread(new ThreadStart(DisplayWaitDialog));
            waitDialogThread.SetApartmentState(ApartmentState.STA);
            waitDialogThread.Priority = ThreadPriority.Highest;
            waitDialogThread.Start();
        }
 
        public void Stop(Form formToRefresh)
        {
            if (waitDialogThread != null)
            {
                waitDialogThread.Abort();
 
                if (waitDialogThread.IsAlive)
                    waitDialogThread.Join();
 
                if (formToRefresh != null)
                {
                    formToRefresh.Focus();
                    formToRefresh.Activate();
                    formToRefresh.Refresh();
                    formToRefresh.BringToFront();
                }
            }
        }
 
        /// <summary>
        /// Display a wait dialog in a new thread for Excel export.
        /// </summary>
        public void DisplayWaitDialog()
        {
            Point locationToDisplay = new Point(location.X + 407, location.Y + 329);
 
            WaitDialog wd = new WaitDialog(textToDiplay, locationToDisplay);
            Application.EnableVisualStyles();
            Application.Run(wd);
        }
    }
}

Ma fenêtre s'affiche parfaitement et cela marche relativement bien.

Lorsque j'ai finis mon traitement, je fais un Abort() sur mon Thread, c'est très sale et dans certains cas précis, ca plante car mon application reste bloquée son mon Join() => Je fais le Join afin d'attendre que le Thread soit fermé.

Ce que je voudrais : Communiquer avec mon thread afin de lui dire de closer sa fenêtre proprement.

Avez-vous une idée?

[Guulh]

Hello,
connais tu le BackGroundWorker ? En gros, tu lui donnes une méthode, qu'il exécute dans un thread séparé ; quand il a fini, il lève un événement dans le thread de ta form, et ferme son thread de travail. Ça évite de se farcir la gestion de thread à la mano, très pratique

[Vonziz]

Merci pour cette orientation. Ce composant m'a l'air pas mal, il faudra juste que je fasse certaines modifications car je voyais les choses inversements : je faisais mes traitements dans mon thread principal et ma frame d'attente dans mon thread séparé alors que là, c'est l'inverse...

N'est-ce pas compliqué à débugger après? Le thread exécuté par le BackGroundWorker?

Je recommande cette documentation très bien faite sur le BackGroundWorker :
http://glarde.developpez.com/dotnet/bgworker/cs/

[Vonziz]

J'ai une question tout de même, mes traitement lourds mettent à jour mes frames, est ce que le BackGroundWorker gère l'accès aux Forms de mon Thread principal?

[Guulh]

J'ai une question tout de même, mes traitement lourds mettent à jour mes frames, est ce que le BackGroundWorker gère l'accès aux Forms de mon Thread principal?

Il n'est pas possible (en fait si mais ça amène des tas d'embrouilles) de modifier l'UI dans un autre thread que le sien.

C'est (entre autres) pour ça qu'un développement en couches est préconisé, afin de séparer le métier de sa représentation. D'un côté, des méthodes sans rien de graphique, lourdes, avec des calculs, des appels à une source de données (via éventuellement des sous-méthodes des couches encore inférieures), etc. ; de l'autre, une couche avec des méthodes chargées simplement de la représentation des données métier.
A ce moment là, seul le code métier est à exécuter dans un autre thread ; la partie graphique, rarement coûteuse, est laissée dans le thread de l'UI.

[Vonziz]

Ok je te remercie pour ton explication détaillée.

Mon application n'ayant pas été conçue à la base sur cette logique de multi-thread pour l'exécution du métier, je n'ai pas le temps d'effectuer une refonte des appels aux diverses fonctions métier.

Une question complémentaire : Le débuggage Visual Studio n'est-il pas galère dans un contexte multi-thread asynchrone?

[Guulh]

Mon application n'ayant pas été conçue à la base sur cette logique de multi-thread pour l'exécution du métier, je n'ai pas le temps d'effectuer une refonte des appels aux diverses fonctions métier.

Ce que tu peux faire, par contre, si tu veux modifier les contrôles alors que ton thread courant n'est pas celui de l'UI, c'est d'utiliser le pattern if (this.InvokeRequired) this.Invoke (...) else { ... }, que je ne détaille pas ici parce qu'il revient souvent sur le forum (je l'ai vu y'a moins de trois jours ; une petite recherche de ces mots-clé t'y mènera vite)

Une question complémentaire : Le débuggage Visual Studio n'est-il pas galère dans un contexte multi-thread asynchrone?

Dans VS, il y a une fenêtre "threads", qui permet de basculer entre les différents threads actifs. C'est certes plus complexe que du mono thread mais dans les cas simple c'est pas insurmontable.