Discussion :

[tribaleur]

Bonjour à tous.

Je développe un application dans la quelle à un moment donné je doit sauvegarder des données dans une base SQL. Jusqu'ici tout va bien.

Pendant que je sauvegarde j'affiche un petit label en plein milieu de l'écran pour avertir les utilisateur qu'un traitement est en cour.

Mon label est tout simple, couleur de fond de base, simple contour noir, écrit en Noir Gras. Je l'affiche au tout début de ma fonction de sauvegarde ... et le cache à la fin. Il est créé sur ma forme et est invisible par défaut.

Seulement voila, le traitement derrière est lourd et du coup si je n'utilise pas DoEvents ... le label n'affiche que son contour

Cependant j'ai lus que DoEvents était du passé et que maintenant il y avait les thread ... et que ceux-ci permettait de passer outre DoEvents.

Comme j'aime faire les choses bien proprement, je me demandais donc si utiliser des thread pour un simple label ne serai pas un peu lourd...voir inutile.

Je viens donc vous demander vos avis éclairés

D'avance merci.

[GuruuMeditation]

En théorie, DoEvent c'est le mal incarné
mais en pratique, pour des cas simples, pourquoi pas.

[tribaleur]

Tiens d'ailleurs ta remarque me fait penser à une question :
-Pourquoi DoEvents est-il le mal incarné?

En tout cas merci de ta réponse même si elle ne répond pas entièrement à ma question

[GuruuMeditation]

En gros DoEvent suspend le thread, mais continue de traiter les messages Windows. Et si un de ces message déclenche un événement dans ton appli, tu peux te retrouver dans un état instable. Voila pourquoi MS déconseille son utilisation.

[tribaleur]

Je te remercie pour ton explication.
Je ne savais pas comment il fonctionnait et je croyais qu'il bloquait toutes nouvelles instructions jusqu'à ce que celles en cours sois finies.
Mais en vus de ton explication je comprend le risque de l'utiliser.

Merci à toi.

[GuruuMeditation]

De rien! Maintenant, si c'est une appli perso pas trop complexe, je l'ai déjà utilisé par facilité. Mais dans un environnement pro complexe, j'éviterais.

[Graffito]

je me demandais donc si utiliser des thread pour un simple label ne serai pas un peu lourd...voir inutile.

Dans ce cas, même si le DoEvents() est comme l'indiquait GurruuMeditation plus simple (mais moins "safe"), la solution appropriée est un BackGroundWorker.
voir : http://webman.developpez.com/article...ckroundworker/

[tribaleur]

Bonjour à tous et surtout merci pour vos réponses.

Du coup je me suis renseigné sur les thread pour comprendre comment fonctionnaient les BackGroundWorker (j'aime comprendre ... ou au moins essayer )

Et du coup je suis tombé sur les Delegate (queje connaissais sous le nom de "Hook" jusqu'à maintenant )

Suite à ça j'ai fait quelques tests sans utiliser les BackGroundWorker ... et en fin de compte le simple fait d'utiliser un Delegate pour appeler ma fonction de refresh de mon Label et de la progres bar qui va avec ... et ça fonctionne.

Voici le code en gros :

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
'Déclaration du Delegate dans ma classe (ne fonctionne pas en local apparement)
Public Delegate Sub Hook_PGB_Update(ByVal Valeur As Integer)
 
...
Private Sub Test (ByRef FormM as Form_Main, ByRef FormL as Form_Load)
'Form_Main est mon formulaire principal
'Form_Load est le formulaire qui contient mon Label et ma progresse bar
 
        'Déclare la variable qui permettra d'utiliser le Delegate pour appeler la fonction
        Dim HK As Hook_PGB_Update = (AddressOf FormL.PGB_Update)
 
        'Défini la valeur du progresse bar
        HK.Invoke(20) 'Fonctionne bien, les controle du form_Load sont bien affichés
        FormL.PGB_UpDate(20) 'Les controls ne sont pas affichés correctement
 
...
 
End Sub
 
'La fonction sur mon autre formulaire
Public Sub PGB_Update(ByVal Valeur As Integer)
        'Controle le paramètre de valeur de la progresse bar
        If Valeur > 100 Then Valeur = 100
        If Valeur < 0 Then Valeur = 0
        'Met à jour la progresse bar avec la nouvelle valeur
        Me.PGB_Save.Value = Valeur 
        Me.PGB_Save.Refresh()
        ' Refresh le Label
        Me.LB_Enregistrement.Refresh()
End Sub

J'avoue ne pas bien comprendre pourquoi ça fonctionne avec le Delegate et pas si j'appelle en direct.
Je pense que c'est par-ce que quand j'appelle en direct, le calcul de l'affichage des controls ce fait dans le thread de mon formulaire principal ... qui est ensuite "bloqué" par le lourd traitement derrière.

Alors qu'avec le Delegate, ça calcul l'affichage dans le Thread du Form_Load qui lui est libre à la fin de la fonction.

Mais je suis pas sur. Si quelqu'un pouvait me confirmer/Infirmer ma théorie ce serai super.

En tout cas merci de votre aide.

[Mat.M]

Salut DoEvents est une solution toute simple mais tu ne contrôles pas la synchronisation des processus.
Donc effectivement un thread est peut-être plus approprié

[StringBuilder]

La piste du BackgroundWorker est la plus simple je pense, car très facile à mettre en place (bien plus que du multi-threading classique), et tu pourras même remplacer ton message par une belle progressbar toute belle

Quant à DoEvents, faut laisser ça à VB6, comme le GOTO au Basic