Timer + ProgressBar [Résolu]

Signaler
Messages postés
222
Date d'inscription
mercredi 5 avril 2006
Statut
Membre
Dernière intervention
18 février 2011
-
Messages postés
3877
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
23 août 2018
-
Alors... j'ai cherché rapidement et j'ai pas vraiment trouvé de solution "claire", DONC :

- j'ai une form"appelante", et une form"destination".
- sur le clique d'un bouton de la form"appelante", un gros traitement s'effectue (requêtes SQL + affichage dans la form"destination") et affichage de la form"destination".
- durant le traitement, pour faire patienter l'utilisateur, j'affiche une form"traitement" avec juste un label"traitement en cours".
- j'aimerais ajouter à la form"traitement" une progressbar, ainsi qu'un timer permettant le défilement de la progressbar (environ 45sec en moyenne, c'est pas grave si le traitement est un peu + ou - long selon les critères).

MON PROBLèME !!!! j'ai tout "retourné", dans tous les sens, les "DoEvents", les Timer, ProgressBar etc... et dans tous les cas, je n'arrive pas à "passer" dans le timer, ou plus concrètement à faire "défiler" la progressBar... Merci de m'indiquer le processus, si possible, ou m'indiquer si il y a des problème généraux à cette action, à savoir "c'est pas possible de le faire", dans ce cas je laisserais unqiuement le "label", en fait c'est juste pour la présentation donc pas très grave pour l'application mais ça serait bien que je sache... merci

''***************************************************************************
...à votre service
Thanks & Peace
Tonio
A voir également:

7 réponses

Messages postés
4030
Date d'inscription
mardi 13 mai 2003
Statut
Modérateur
Dernière intervention
23 décembre 2008
22
Salut,

Normalement, si ton traitement est long et prend toutes les ressources, c'est normal de ne pas voir la progressBar.
Si ton traitement est long, c'est surement parce qu'il effectue une boucle de quelques dizaines (centaines ? milliers ?) d'itérations.
C'est donc à l'intérieur de cette boucle (ou de ces boucles) que tu dois placer une instruction DoEvents.

Ainsi, tu rendras la main à ton application (et accessoirement à ta progressBar) très souvent.

DoEvents alloue une micro-dose de CPU au reste de l'application. Il faut en faire énormément pour avoir l'impression que l'application continue à réagir pendant le traitement.
A noter que DoEvents ralentit considérablement ton temps de traitement. De 45s, tu pourrais bien passer à plusieurs minutes .... mais avec un Timer et une progressBar

Manu
--------------------------------------------------------------------------------------------
Avant de poster un message, n'oubliez pas de consulter le reglement.
Messages postés
918
Date d'inscription
vendredi 3 août 2007
Statut
Membre
Dernière intervention
27 octobre 2008
10
Ce qui ce passe aussi sans doute, c'est que le plus gros de ton traitement semble êtr eune requête SQL sur une DB ! Or, il y a de forte chance pour que tu es lancé cette requête en mode synchrone !! Donc, mettre un Doevents avant ou après n'y fera rien.
Regarde plutôt sur la façon de faire des requêtes en mode asynchrone. Je ne me souvient pas bien comment on fait, car je n'ai utilisé cela qu'une fois (et plus le code sous la main)
Messages postés
222
Date d'inscription
mercredi 5 avril 2006
Statut
Membre
Dernière intervention
18 février 2011
3
au lieu de "DoEvents" bien placés, j'opte finalement pour des "Frm_Client_Recherche.ProgressBar1.Value = ...." bien placés (après chaque requêtes, en comptant à peu près le temps pour chaque requête, environ 5 secondes) afin d'éviter le "Timer". Pas terrible mais bon, on fait avec les moyens du bord.

''***************************************************************************
...à votre service
Thanks & Peace
Tonio
Messages postés
222
Date d'inscription
mercredi 5 avril 2006
Statut
Membre
Dernière intervention
18 février 2011
3
Ok, j'essaie avec un "DoEvents" avant et après chaque requête. J'espère que ça ira. En gros, tu me confirmes que "techniquement", niveau ressource, c'est pas forcèment "possible". Now je sais et ça confirme un peu se que je pensais. Cependant j'essaie avec plusieurs DoEvents "bien placés".

''***************************************************************************
...à votre service
Thanks & Peace
Tonio
Messages postés
883
Date d'inscription
vendredi 3 novembre 2000
Statut
Membre
Dernière intervention
3 mars 2009
7
econs, ta description de DoEvents est un peu étrange si je peux me permettre.
En pratique DoEvents, traite les messages en attente sur le processus en cours. Donc s'il n'y a pas de messages, DoEvents ne prend (quasi) pas de temps, par contre s'il y a des messages (comme l'évènement Tick de ton Timer, ou l'utilisateur qui interragit avec la fenêtre etc...) ils seront tous traités, peu importe le temps que ça prendra. Un DoEvents toutes les secondes de traitement est donc largement suffisant...

Sinon pour le reste, moi ce qui me chiffonne c'est l'histoire des 45 secondes, pour peu que tu sois sur une machine différente ou que ton cpu soit occupé, le temps de traitement ne sera plus (du tout) de 45 secondes.
Tu ne sais pas prédire l'avancement du traitement autrement ? Tu ne connais pas le nombre d'itérations totales ou quelque chose du genre ?

<hr size="2" width="100%" />Julien.
Messages postés
883
Date d'inscription
vendredi 3 novembre 2000
Statut
Membre
Dernière intervention
3 mars 2009
7
Excellente idée ! C'est en effet une bien meilleure solution...

<hr size="2" width="100%" />Julien.
Messages postés
3877
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
23 août 2018
18
Antoine,
je ne suis pas certain de comprendre ce que tu entends par
"en comptant à peu près le temps pour chaque requête".

En fait, une fois ta requête effectuée, si tu utilises Recordcount, tu sauras combien d'enregistrements il y a à afficher, donc quel est le pourcentage à affecter à la barre de progression... Donc, si tu utilises la méthode classique du Do Until Rs.EOF ou While ...
tu passes par un Movenext qui peut déterminer le moment du changement de la barre... Mais on parle peut-être de la même chose finalement...

MPi²