La galère des Threads sous .NET 2.0 :-)
On s’est retrouvé, ben et moi, lors de l’ecriture de notre logiciel Skin.be dans une petite galère avec l’utilisation des Threads sous le .NET 2.0 !
C’est quoi un thread ?
Lorsque vous démarrez une application, Windows crée automatiquement un nouveau « thread » d’exécution spécialement pour votre application. Ce « thread » permet d’isoler votre application dans son propre environnement unique, bien séparé de tout autre application. Attention, il ne faut pas les confondre avec les AppDomain ! Un thread est une « unité d’execution » alors qu’un domaine d’application et une « unité d’isolation d’execution » !! J’eclaircirai tout cela plus tard…
A quoi ca sert un thread ?
Les threads permettent d’effectuer plusieurs taches dans votre programme en même temps : le multi-tache ! Imaginez un serveur web mono-thread où 2 clients se connecte en meme temps : 1er arrivé, 1er servi : 1 seul client à la fois ce qui n’est pas super !! Hors avec les threads, dès qu’un client se connecte, un nouveau thread est lancé independement des autres pour pouvoir « s’occuper » de nouveau client !
Rapport entre Skin.be et les threads
Dans notre petit logiciel, quand vous cliquez sur « Télécharger », une fonction est appellée et vient faire une boucle pour télécharger toutes les images. Seulement cette fonction étant très gourmande et étant executée dans le meme thread fige l’interface graphique !
Notre programme devient donc tout « blanc » (plus de rafraichissement graphique) et on peut plus le controler a moins d’attendre la fin du téléchargement ! Pas génial hein !
Donc pour remedier a cela, nous executons la fonction de téléchargement dans un autre thread ce qui permet de garder le contrôle sur notre GUI (interface graphique du programme).
La où ca devient galère !
Le probleme dans notre cas, c’est qu’a chaque image téléchargée, notre fonction de Telechargement rafraichit la GUI au moyen d’une ProgressBar (10%..20%..30%…) et d’un petit label: « Telechargement de la photo 2/8 ».
Seulement sous .NET 2.0, si vous modifiez un controle d’un autre thread vous aurez un beau message de votre compilateur :
Illegal cross-thread operation: Control ‘ProgressBar’ accessed from a thread other than the thread it was created on
Le .NET framework 2.0 détecte lui même que l’on cherche a modifier une propriété du label dans un autre thread que le thread principal ce qui provoque cette erreur !
Comment fait on alors ?
Il faut en fait demander au contrôle d’effectuer lui même la resynchronisation ! Pour cela on va utiliser des délégués.
Déclarons-le au debut de notre programme :
1 | Private Delegate Sub SyncroControl(ByVal sender As System.Object, ByVal e As System.EventArgs) |
Puis dans votre code, créez une fonction pour la mise a jour de votre contrôle (ou vos contrôles) :
1 2 3 4 5 6 | Private Sub UpdateControlProgress(ByVal sender As System.Object, ByVal e As System.EventArgs) Dim i As Integer = CInt(sender) Dim progress As Decimal = 100 / nb_photos ProgressBar.Value = CInt(progress * (i + 1)) Label4.Text = "Téléchargement photo " & (i + 1) & "/" & nb_photos End Sub |
Dans notre cas la fonction UpdateControlProgress récupérera l’avancement dans l’objet sender qui sera convertie en Integer, puis on viendra mettre a jour notre ProgressBar et label en fonction.
Il ne reste plus qu’a appeler cette fonction par notre délégué dans le code de votre Thread :
1 2 | Dim monDelegue As New SyncroControl(AddressOf UpdateControlProgress) ProgressBar.Invoke(monDelegue, New Object() {i, EventArgs.Empty}) |
(nb: i est un Integer representant l’avancement du téléchargement dans notre application !)
C’etait simple non ? 🙂