Barre de progression

Le
WebAutoSubscriptions
Bonjour,

je travaille sur une appli qui indexe le contenu d'un répertoire dans
une base de données.
L'algo rentre dans un dir, compte les fichiers, stocke en db et
parcourt le reste des sous-rep et ainsi de suite.
Je cherche à faire une barre de progression ms mon pb est le suivant :
qd je rentre dans un répertoire, qui contient disons que j'ai 5
fichiers et 1 sous-rep.
La progression est à 0 au début normal.
Je boucle et ma progression est donc de 1/5 puis 2/5
j'arrive à mon sous dossier qui contient 99 fichiers par ex donc, je
passe à :
6 (5 fich + 1 rep) / (6 + 99) -> la progression totale redescend, ce
qui est logique, au regard de ce que l'appli a découvert dans le sous-
répertoire.

Mon pb : le user va être troublé de voir sa progression passer de 20%
- 40% - 60% - 80% et boum, d'un seul coup à 10 % environ .
Par rapport à une progression classique, je ne sais pas à l'avance
combien j'ai de fichiers à traiter, j'avais pensé faire un premier
thread de pré-scannage ms ca peut être longuet -> pas terrible
Windows fait un genre de truc pareil avec sa "préparation de la copie"
ms j'ai pas trop d'idées alors si qqun a une idée je vous en
remercie d'avance

Cdlt,
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain SF
Le #16466391
wrote on 02/08/2008 23:05:

Par rapport à une progression classique, je ne sais pas à l'avance
combien j'ai de fichiers à traiter, j'avais pensé faire un premier
thread de pré-scannage ms ca peut être longuet -> pas terrible...
Windows fait un genre de truc pareil avec sa "préparation de la copie"
ms j'ai pas trop d'idées alors si qqun a une idée... je vous en
remercie d'avance ...



windows fait cette débilité en effet avec le quasi-doublement du temps
de process comme conséquence.

MacOS 7 (déjà) affichait une barre de progression infinie sous forme
de chevrons animés ( meilleure façon pour un process de temps indéterminé.

or barre de prog., tu peux également afficher le nombre (global) de
fichiers traités, l'utilisateur verra que le soft tourne toujours.

Sylvain.
Christian Laborde
Le #16468431
Cela dit, explorer les sous répertoires et compter le nombre de fichiers ne peut
prendre beaucoup de temps.
Salut.

Sylvain SF a écrit :
wrote on 02/08/2008 23:05:

Par rapport à une progression classique, je ne sais pas à l'avance
combien j'ai de fichiers à traiter, j'avais pensé faire un premier
thread de pré-scannage ms ca peut être longuet -> pas terrible...
Windows fait un genre de truc pareil avec sa "préparation de la copie"
ms j'ai pas trop d'idées alors si qqun a une idée... je vous en
remercie d'avance ...



windows fait cette débilité en effet avec le quasi-doublement du temps
de process comme conséquence.

MacOS 7 (déjà) affichait une barre de progression infinie sous forme
de chevrons animés ( meilleure façon pour un process de temps indéterminé.

or barre de prog., tu peux également afficher le nombre (global) de
fichiers traités, l'utilisateur verra que le soft tourne toujours.

Sylvain.



--
Christian Laborde
La Révolution citoyenne, c'est sur : http://c.lab.over-blog.com/
Le forum des électrons libres : http://electrons-libres.forumactif.fr
True E-mail : remove -no-spam-
Rte de la Conversion, 20
CH 1095 Lutry
Suisse
Sylvain SF
Le #16469841
Christian Laborde wrote on 03/08/2008 13:53:
Cela dit, explorer les sous répertoires et compter le nombre de fichiers
ne peut prendre beaucoup de temps.



"ne peut prendre" doit être lu comme "peut ne pas prendre bcp de temps"?

si c'est le cas, c'est à dire s'il y a peu de fichiers à copier, la
barre de progression servira généralement à rien car le process complet
sera généralement rapide, dans ce cas la fenêtre de progression ne
devrait pas êre affichée du tout - inutile de faire clinoter une fenetre
que l'on n'a pas le temps de lire, celle-ci ne doit apparaitre qu'après
un certain de temps (3 à 8 sec.) si le temps restant est significatif.
(ok, il y a toujours le cas du fichier unique de plusieurs giga, vous
savez si vous êtes dans ce cas ou non).

dans les autres cas, nombreux fichiers dans de nombreux sous-répertoires
ce temps d'exploration est très loin d'être négligeable.

la solution à retenir n'est pas technique mais plus dictée par le type
d'utilisateur, s'ils veulent un traitement rapide, évitez la barre et
le temps d'exporation, s'ils préfèrent les machins qui clignotent,
mettez cette barre.

Sylvain.
Emmanuel Bourg
Le #16469831
Tu peux aussi faire les deux en même temps

- un premier thread qui scan les fichiers et fait le vrai boulot

- un deuxième thread qui scan les répertoires pour compter le nombre de
fichiers.

Tant que le 2eme threads n'a pas terminé ta barre de progression tourne
en mode indéterminé, et dès qu'elle a terminé tu affiches la progression
réelle.
WebAutoSubscriptions
Le #16477381
Bonsoir et merci pour vos réponses.
J'avais implémenté la dernière solution avec 2 threads, le pb est que
cela fait faire inutilement la navette à la tête de lecture sur le
disque -> Le process met bcp de plus de temps, finalement. (je cite :
quasi-doublement du temps
de process comme conséquence. )

Il s'agit en fait de dizaines de fichiers sur un dvd.

La barre de progression infinie me plaît bien, finalement à l'usage :)
Car le process peut être assez long en effet.

Je n'ai donc pas loupé la solution miracle, je suis content :)

Merci à tous et bonne soirée !
Emmanuel Bourg
Le #16479181
a écrit :
Bonsoir et merci pour vos réponses.
J'avais implémenté la dernière solution avec 2 threads, le pb est que
cela fait faire inutilement la navette à la tête de lecture sur le
disque -> Le process met bcp de plus de temps, finalement. (je cite :
quasi-doublement du temps
de process comme conséquence. )



A réessayer dans 10 ans quand nous aurons tous des SSD dans nos
ordinateurs :)
Sylvain SF
Le #16480861
a écrit :

A réessayer dans 10 ans quand nous aurons tous des SSD dans nos
ordinateurs



un disque à techno statique aiderait, le file system lui-même peut
également aider, par exemple si les entrées répertoires stockaient
le nombre de sous-élements et leur taille totale; même si sur fclj
la solution risque de ne pas être OS indépendante.

Sylvain.
Publicité
Poster une réponse
Anonyme