je travaille sur une appli qui indexe le contenu d'un r=E9pertoire dans
une base de donn=E9es.
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 =E0 faire une barre de progression ms mon pb est le suivant :
qd je rentre dans un r=E9pertoire, qui contient disons que j'ai 5
fichiers et 1 sous-rep.
La progression est =E0 0 au d=E9but normal.
Je boucle et ma progression est donc de 1/5 puis 2/5
j'arrive =E0 mon sous dossier qui contient 99 fichiers par ex donc, je
passe =E0 :
6 (5 fich + 1 rep) / (6 + 99) -> la progression totale redescend, ce
qui est logique, au regard de ce que l'appli a d=E9couvert dans le sous-
r=E9pertoire.
Mon pb : le user va =EAtre troubl=E9 de voir sa progression passer de 20%
- 40% - 60% - 80% et boum, d'un seul coup =E0 10 % environ ....
Par rapport =E0 une progression classique, je ne sais pas =E0 l'avance
combien j'ai de fichiers =E0 traiter, j'avais pens=E9 faire un premier
thread de pr=E9-scannage ms ca peut =EAtre longuet -> pas terrible...
Windows fait un genre de truc pareil avec sa "pr=E9paration de la copie"
ms j'ai pas trop d'id=E9es alors si qqun a une id=E9e... je vous en
remercie d'avance ...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sylvain SF
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 (<http://cjoint.com/?ida3hEGqyF>), cela reste la 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.
WebAutoSubscriptions@gmail.com 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 (<http://cjoint.com/?ida3hEGqyF>), cela reste la
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.
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 (<http://cjoint.com/?ida3hEGqyF>), cela reste la 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
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 (<http://cjoint.com/?ida3hEGqyF>), cela reste la 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
Cela dit, explorer les sous répertoires et compter le nombre de fichiers ne peut
prendre beaucoup de temps.
Salut.
Sylvain SF a écrit :
WebAutoSubscriptions@gmail.com 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 (<http://cjoint.com/?ida3hEGqyF>), cela reste la
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
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 (<http://cjoint.com/?ida3hEGqyF>), cela reste la 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
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.
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.
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
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.
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.
- 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
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 !
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 :)
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
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 :)
WebAutoSubscriptions@gmail.com 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 :)
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
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.
WebAutoSubscriptions@gmail.com 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.
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.
