TRAITEMENT DE TRAITEMENTS LONGS.

Commentaire de Loda le 21/06/2007 15:01:14

oui, il manquait la capture d'écran. MDR !

A+

Loda

PS: je regarderais ça avec attention quand il y aura les sources ;-)

Commentaire de John Dogget le 21/06/2007 16:00:59

C'est mieux avec les sources :)

Concernant la sources, est ce que ce n'est pas mieux d'inclure ce genre de code directement dans les traitements que dans une unité à part ?

Je m'explique ...

Si je prends l'exemple simple d'une copie de fichier "custom" qui n'utilise pas les API.
Le temps indiqué et la progression peuvent dépendre de pleins de choses (charge CPU, fragmentation etc). Alors comment quelque chose d'externe à ces traitements pourrait'il etre au courant de tout ça ?

J'ai du mal à expliquer ce que je veux dire, je vous felicite si vous m'avez compris :D ...

Commentaire de Caribensila le 21/06/2007 16:27:58

... Je précise que le temps restant calculé n'est qu'une estimation. Mais cette estimation est évaluée à chaque pas du Timer. Elle pourra donc varier en fonction de la charge du CPU, par exemple.

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 22/06/2007 12:43:52

Je me trompe peut-être, mais il me semble que beaucoup d'entre vous ont des doutes sur ce code  ;)

Donc, pour en avoir le coeur net, j'ai fait une MAJ en ajoutant une simulation de chargement de fichier sur Internet.

Conclusion, après quelques estimations fantaisistes dans les premières secondes, l'application donne une estimation très correcte du temps restant. Et plus le temps passe, plus l'estimation s'affine.
Après réflexion, il ne semble pas qu'on puisse faire plus précis.

En espérant avoir dissiper quelques doutes...  :)

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é ? :(