TRAITEMENT DE TRAITEMENTS LONGS.

Commentaire de John Dogget le 21/06/2007 14:59:12

Manquerait pas quelque chose par hasard :p ?

Commentaire de John Dogget le 21/06/2007 15:11:53

Ben oui, il manque les sources (c'est pas rien) !!

:D

Commentaire de Caribensila le 21/06/2007 16:10:55

Salut,

Bein, la progression est incrémentée par l'appel régulier d'une fonction de l'unité Wait, et ceci depuis la boucle provoquant l'attente. La progression reflète donc exactement ce qui est en train de se passer.

Si j'ai bien compris ce que tu voulais dire...  :)

Commentaire de florenth le 21/06/2007 16:39:52

Hum, ce code source me laisse dubitatif ...

Déjà, je salue l'idée. Car par les temps qui courent, on voit de moins en moins ce genre de précautions, on ne dit même plus à l'utilisateur "je travaille", c'est à lui de le deviner. Rien que pour ça, je dis bravo.

Après, niveau code, j'ai du mal à voir dans quels cas on pourrait utiliser un tel mécanisme ? Je veux dire, concrètement... tous les traitements longs ne sont pas des boucles. Tous les traitements longs ne s'arrêtent pas dans la seconde qui suit. Surtout lorsqu'on utilise des APIs qui travaillent sur les fichiers ou sur internet.
Comment adapter ton code dans ces cas là ?
Et puis, tout traitement long ne devrait-il pas être encapsulé dans un thread qui se chargerait d'indiquer par messages (pas pas synchro, on perd trop de temps) son état ?

Pour le calcul du temps restant: pour être davantage précis, il faudrait se baser sur les dernières secondes écoulées du calcul. Car, en effet, si tu démarres la tache alors qu'il n'y a aucun programme d'ouvert, ça ira vite. Si, au milieu de la tâche, tu as une soudaine envie de lire tes mails, le programme (Thunderbird que je conseille) va la ralentir et le temps restant sera erroné !

Commentaire de Caribensila le 21/06/2007 16:50:57

@ Florent:
Quand tu travailles sur Internet, par exemple, il est impossible d'évaluer le temps restant. Dans ce cas, tu ne peux dire à l'utilisateur qu'une tâche est en cours et éventuellement le renseigner sur l'avancement de la tâche.
Dans ces cas là, mon code ne donne que le temps écoulé depuis le début.
Il ne peut pas faire l'impossible, hélas...  ;)

"Pour le calcul du temps restant: pour être davantage précis, il faudrait se baser sur les dernières secondes écoulées du calcul."
Je vais y réfléchir... :)))

Commentaire de Caribensila le 21/06/2007 17:08:18

De toute façon, sur Internet, les estimations sont toujours hautement fantaisistes. Et je ne vois pas comment on pourrait les affiner a priori.
Mais ça vaut le coup d'y réfléchir. C'est intéressant.  :)

Commentaire de florenth le 22/06/2007 13:25:45

"beaucoup d'entre vous ont des doutes sur ce code"

Tiens, j'ai l'impression de faire parti du lot ! ^^
Le truc, c'est que je n'ai pas compris comment m'en servir dans le cas d'un VRAI téléchargement de fichier sur Internet. Ta simulation est bonne, le calcul du temps restant aussi mais il manque encore un petit quelque chose pour que je puisse comprendre.

En fait, si, j'ai compris (pas idiot non plus le type ^^). Si on utilise un TIdHTTP il suffit de mettre Initialiser(...) et OuvrirAttente(...) dans le OnBeginWork, le MAJ(...) dans le OnWork et le FermerAttente(...) + Finaliser(...) dans le OnEndWork.

Bon. De ce côté là c'est OK. Mais pour la fin, tu fais comment ? Il faut tester la valeur de FinDemandee dans le OnWork et demander l'annulation si demandé ? Logiquement oui (et ça marche en plus ^^).

Cependant, si ma tâche est threadée, je fais comment ? Il faudrait que je lise la variable FinDemandee pour savoir si c'est la fin. Jusque là, c'est OK. Mais si ce n'est pas la fin, je dois synchronizer le thread avec le thread principal pour pouvoir mettre à jour la barre de progression. Conclusion: je perds du temps.

Ce n'est pas impossible pour autant même si ce n'est pas 100% optimimsé.

---------------------------------------------------------------

Maintenant, imaginons quelque chose de beaucoup plus complexe.
J'utilise la (fameuse ?) API DeviceIOControl() pour faire plein de trucs sympas et bizarres qui prennent du temps.
Cette fonction ne crée aucun callback et la seule façon de l'arrêter est de faire un CancelIO().
Il est possible d'obtenir l'avancement avec GetQueuedCompletionStatus().
Bon.
Comment je m'y prend moi pour gérer ce cas ?

Vu ton code, une seule solution:
- Je lance le tâche (tout le bazar de début des API Windows...)
- Je crée une boucle qui a pour rôle d'appeler périodiquement GetQueuedCompletionStatus()
- A chaque renvoi d'avancement, je mets à jour la progressbar.
- Si l'utilisateur demande d'annuler, il y aura un test dans la boucle qui se chargera d'appeler CancelIO().

Et ça marche ! Mais c'est drôlement compliqué ! Et en plus, tout se fait dans le thread principal.
N'y aurait-il pas un moyen plus simple de faire la même chose ?
C'est cela que je te demande...

PS: Je sais, je vais chercher vraiment loin, mais c'est pour voir jusqu'où tu es capable d'améliorer ta source ! ça n'enlève rien à sa qualité et à l'estime que j'ai d'elle !

Commentaire de Delphiprog le 23/06/2007 22:58:12 administrateur CS

Salut à tous,

"Pour ce qui est des applications threadées, j'avoue que ça dépasse encore mes limites."
Je crois que c'est davantage une question d'appréhension que de difficultés techniques tant la mise en oeuvre avec Delphi est simple. Il suffit d'éviter quelques pièges grossiers et l'on obtient une application qui continue de répondre même en cas de traitement long. Par ce côté, ça rassure déjà l'utilisateur final.

Tu t'est inspiré du code d'Olivier DAHAN : je vois que monsieur a de bonnes lectures :)
Mais ce code, et vous êtes plusieurs à l'avoir fait remarquer, est conçu pour un usage simple et rapide. Il ne saurait régler tous les cas possibles.

Je suis assez étonné que personne n'ait mentionné l'utilisation de callbacks, encore plus simples à mettre en oeuvre pour un résultat plus facilement personnalisable. En effet, tant qu'on transmet une fonction ou une méthode dont la signature correspond à celle attendue par la fonction appelée, on peut faire varier les effets d'une progression sans avoir à concevoir de fiches spécifiques.
Enfin, peut-être que cetet notion de fonction callback est quelque chose qui se perd...
Après tout, pourquoi faire simple quand on peut faire compliqué ? :(