Discussion :

[jlalexie]

Bonjour,
Dans le code qui suit la mise à jour du champ: message.Text = "Programmateur EIB connecté" s'effectue après:
system.Threading.Thread.Sleep(5000)

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
 
 REM ouverure port com série
        Try
            com_prog = My.Computer.Ports.OpenSerialPort(EB400_1.port_name, 9600)
        Catch ex As Exception
            MessageBox.Show(ex.Message)
            Return
        End Try
        com_prog.ReadTimeout = 5000          'timeout 5 s
        System.Threading.Thread.Sleep(100)   'tempo 100ms
 
        REM connection programmateur
        Try
            com_prog.Write(Chr(fprog.pc_connect))
            c = com_prog.ReadByte()
        Catch ex As Exception               'programmateur non connecté
            MsgBox(EB400_1.port_name & "  " & ex.Message)
        End Try
        If c = Asc(ack) Then
            message.Text = "Programmateur EIB connecté"
        Else : MsgBox("Programmateur EIB non connecté !!! code: " & c)
            com_prog.Close()
            Return
        End If
        System.Threading.Thread.Sleep(5000)   'tempo 100ms

Que faut-il faire pour forcer cette mise à jour ?

Merci pour vos réponses.

[tomlev]

Il faut savoir que quand tu exécutes quelque chose sur le clic d'un bouton, par exemple, ce code s'exécute sur le même thread que celui qui met à jour l'interface graphique (UI). Donc tant que ton code n'a pas "rendu la main", aucune mise à jour de l'interface graphique ne peut se faire, ce qui inclut le changement du texte d'un label. Là, tu changes la valeur de la propriété Test, mais l'UI n'a pas l'occasion de se redessiner pour refléter ce changement, puisque le Thread.Sleep empêche la méthode de rendre la main.

La solution simple mais pas très propre est d'appeler Application.DoEvents après le changement de la propriété Text : ça va donner l'occasion à la fenêtre de traiter les évènements "en attente". Par contre, dans les cas un peu complexes ça peut poser des problèmes difficiles à déboguer...

La solution correcte est d'effectuer tous les traitements longs dans un thread différent de celui de l'UI. Pour faciliter un peu les choses, tu peux utiliser le composant BackgroundWorker. Fais une petite recherche sur Google, tu trouveras plein d'infos là-dessus.

[jlalexie]

OK merci pour l'info, je vais essayer.

[-N4w4k-]

Bonjour,

je suis train de créer une application qui demande une tempo très précise (pour de l'automatisme).
Je viens de tomber sur cette discussion qui m'a interpelé car j'en arrive au même problème.. J'ai bien compris pour le backgroundworker, mais:

Est ce que ça veut dire qu'on doit l'utiliser automatiquement pour faire des mises à jour de l'UI dans une grosse application?

Est ce que cette notion fait partie des design patterns ? facade?

merki
mic

[tomlev]

Est ce que ça veut dire qu'on doit l'utiliser automatiquement pour faire des mises à jour de l'UI dans une grosse application?

Je comprends pas très bien ta question... Le BackgroundWorker ne sert pas à faire les mises à jour de l'UI. Au contraire, il sert à faire des traitements longs qui ne sont pas liés à l'UI. En pratique, comme tu as parfois besoin de mettre à jour l'UI pendant le traitement (barre de progression par exemple), le BackgroundWorker fournit un mécanisme pour le faire facilement (méthode ReportProgress et évènement ProgressChanged)

Est ce que cette notion fait partie des design patterns ? facade?

Non, enfin je crois pas...

[jlalexie]

Voilà: j'ai placé Application.DoEvents() après chaque appel de lecture du port série et cela fonctionne très bien, la mise à jour de l'interface s'effectue sans retard.

[Graffito]

le DoEvents() est une solution simple, mais présente un inconvénient majeur : si on agit sur l'IHM pendant l'exécution d'un traitement qui fait des DoEvents(), on pourra exécuter le code associé à des event des controls de la Form au milieu d'un traitement.

[-N4w4k-]

@tomlev: Ok je vois un peu mieux. Dans mon application, j'ai un module qui se met à jour toutes les millisecondes (qui écoute/écrit des entrées/sorties) et qui met ensuite à jour un certain nombre d'autre module. Jusque là ça marchait très bien mais maintenant j'ai trop de modules qui tourne en même temps, ça commence à ramer.. J'ai jamais eut ce problème avant alors je ne sais pas trop comment m'y prendre, mais je vais chercher du coté du BackgroundWorker qui m’a l'air, d'après cette brève description, tout à fait adapté. Merci pour ces infos.

mic

PS: J'ai fait un petit programme test pour essayer le BackGroundWorker pour ceux que ça intéresse (cf pièce jointe)