Timer + ProgressBar [Résolu]

antoine_ferard 222 Messages postés mercredi 5 avril 2006Date d'inscription 18 février 2011 Dernière intervention - 25 sept. 2007 à 16:11 - Dernière réponse : cs_MPi 3875 Messages postés mardi 19 mars 2002Date d'inscription 17 août 2018 Dernière intervention
- 26 sept. 2007 à 01:38
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
Afficher la suite 

Votre réponse

7 réponses

Meilleure réponse
econs 4066 Messages postés mardi 13 mai 2003Date d'inscription 23 décembre 2008 Dernière intervention - 25 sept. 2007 à 16:23
3
Merci
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.

Merci econs 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 69 internautes ce mois-ci

Commenter la réponse de econs
Meilleure réponse
Kristof_Koder 920 Messages postés vendredi 3 août 2007Date d'inscription 27 octobre 2008 Dernière intervention - 25 sept. 2007 à 16:43
3
Merci
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)

Merci Kristof_Koder 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 69 internautes ce mois-ci

Commenter la réponse de Kristof_Koder
Meilleure réponse
antoine_ferard 222 Messages postés mercredi 5 avril 2006Date d'inscription 18 février 2011 Dernière intervention - 25 sept. 2007 à 17:03
3
Merci
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

Merci antoine_ferard 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 69 internautes ce mois-ci

Commenter la réponse de antoine_ferard
antoine_ferard 222 Messages postés mercredi 5 avril 2006Date d'inscription 18 février 2011 Dernière intervention - 25 sept. 2007 à 16:29
0
Merci
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
Commenter la réponse de antoine_ferard
Julien237 884 Messages postés vendredi 3 novembre 2000Date d'inscription 3 mars 2009 Dernière intervention - 25 sept. 2007 à 16:41
0
Merci
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.
Commenter la réponse de Julien237
Julien237 884 Messages postés vendredi 3 novembre 2000Date d'inscription 3 mars 2009 Dernière intervention - 25 sept. 2007 à 20:54
0
Merci
Excellente idée ! C'est en effet une bien meilleure solution...

<hr size="2" width="100%" />Julien.
Commenter la réponse de Julien237
cs_MPi 3875 Messages postés mardi 19 mars 2002Date d'inscription 17 août 2018 Dernière intervention - 26 sept. 2007 à 01:38
0
Merci
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²
Commenter la réponse de cs_MPi

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.