Osris6880
Messages postés41Date d'inscriptionsamedi 27 décembre 2003StatutMembreDernière intervention12 janvier 2006
-
27 mai 2005 à 11:00
Osris6880
Messages postés41Date d'inscriptionsamedi 27 décembre 2003StatutMembreDernière intervention12 janvier 2006
-
7 juin 2005 à 14:48
Salut à tous
Je souhaiterais pouvoir ouvrir un fichier d'environ 600 Mo.
Puis le mettre dans un Richtextbox, mais je me retrouve à dépasser la capacité du richtextbox ou de la variable.
Il n'y aurait t'il pas un moyen pour ouvrir ce genre de fichier ?
zifnig
Messages postés69Date d'inscriptionvendredi 10 septembre 2004StatutMembreDernière intervention 4 mars 2013 27 mai 2005 à 11:47
Quel est ton besoin?
Si c'est de l'affichage, il te suffit de gérer un index en cohérence entre l'affichage de la richtextbox et le fichier et de lire périodiquement des tranches du fichier et mémoriser ces tranches au fur et à mesure (lire le fichier en random).
Osris6880
Messages postés41Date d'inscriptionsamedi 27 décembre 2003StatutMembreDernière intervention12 janvier 2006 28 mai 2005 à 10:49
J'ai essayé, mais je ne vois pas comment on peut faire pour ouvrir le fichier en plusieurs tranches ?
De
plus je voudrais stocké le fichier. Donc il faut que je l'ouvre et que
je rentre chaques tranches du fichier dans une variable.
Et je ne vois pas comment on peut le faire.
Il faudrait que je puisse lui demander de lire (par exemple) du 15200
octets au 30000 octets et rentrer ce contenu dans une variable.
zifnig
Messages postés69Date d'inscriptionvendredi 10 septembre 2004StatutMembreDernière intervention 4 mars 2013 30 mai 2005 à 13:07
Bizarre, le texte que j'avais tapé n'a pas été pris en compte???
Je le refais en plus court, désolé.
Pour de l'affichage : overture en binary ou random, gestion de l'index avec lecture utilisant le recnumber de l'instruction GET (GET #1,recnumber,variable). recnumber sera soit l'index de l'octet si le fichier est ouvert en binary, soit l'index de la ligne si ouvert en random. Avec ça, tu peux mémoriser un bloc d'index1 à index2 et l'afficher dans ta richtextbox et lorsque tu arrive en fin de richtextbox, tu charge un autre bloc...
Pour du traitement de données, essaye de trouver un traitement itératif qui permet de charger en mémoire un enregistrement à la fois.
Osris6880
Messages postés41Date d'inscriptionsamedi 27 décembre 2003StatutMembreDernière intervention12 janvier 2006 1 juin 2005 à 17:33
En fiate je souhaite copier un gros fichier, mais pas la dll Microsoft
scripting runtime. Ou alors les autre fonction. Car celle ci ne nous
permette pas de voir la progression en temps réél. Donc ce n'est pas
que pour de l'affichage.
zifnig
Messages postés69Date d'inscriptionvendredi 10 septembre 2004StatutMembreDernière intervention 4 mars 2013 3 juin 2005 à 10:29
Tu peux passer par les instruction Open nom_fichier1 For Binary As #1 et Open nom_fichier2 For Binary As #2 pour ouvrir tes fichiers.
Ensuite tu lis le fichier source avec Get #1, , octet et tu écris l'octet dans le fichier cible avec Put #2, , octet.
Pour la barre de progression, il te faut la taille du fichier source que tu affecte à la valeur max de la progressbar (valeur adaptée si nombre trop grand) et tu ajoute 1 à la valeur de la progressbar à chaque fois que tu copies un octet.
Open nom_fic1 For Binary As #1
Open nom_fic2 For Binary As #2
While Not EOF(1)
Get #1, , binvar
Put #2, , binvar
progressbar.value=progressbar.value + int(100/LOF(1))
Wend
Gobillot
Messages postés3140Date d'inscriptionvendredi 14 mai 2004StatutMembreDernière intervention11 mars 201934 7 juin 2005 à 12:09
Lg c'est le nombre d'octets à lire à chaque lancement d'une lecture, c'est aussi la taille du buffer (de 0 à lg-1)
tu peux faire varier la taille de Lg et tu constateras que plus la
taille est petite et plus les temps augmentent, d'un autre côté plus la
progressbar est précise, mais ce n'est pas proportionnel, en
multipliant la taille par 2 par exemple 16k, tu ne diviseras pas les
temps par 2, il y a une taille optimum à trouver, quand la taille est
de l'ordre de quelques octets, les temps sont extrêmement longs, c'est
ce qui devait se passer dans ton programme précédent, ensuite en
augmentant la taille, il y a très peu de différence, entre 1k et 8k
c'est pratiquement identique.
Total c'est la taille totale à copier, et Reste c'est la taille qui reste à copier.
Total n'étant pas forcémént un multiple de Lg, pour la dernière lecture
il va y avoir un reste qui sera plus petit que Lg, donc je ne peux pas
lire 8k octets s'il reste moins à lire, d'où la correction de la taille
de buffer qui détermine le nombre d'octet à lire.
à la fin il faut que je me retrouve avec Reste = 0 ce qui voudra dire
que tout a été lu, pas question de se retrouver avec un reste négatif,
ce qui voudrait dire que j'ai lu plus que nécessaire et que le fichier
en sortie est plus gros que le fichier d'entrée.
ce n'est pas le cas ici, le fichier de sortie aura exactement la même taille.
cas particulier: si tu copie des fichiers plus petit que 8k (taille du
Buffer), à la première lecture, tout le fichier sera lu d'un coup et la
progressbar va faire un bond directement de 0 à 100, c'est
l'inconvénient des gros Buffer, on gagne en temps mais on perd en
précision.