[Novice] Ecrire une ligne en fin d'un fichier texte
15 réponses
Dom
Bonjour à tous,
Je débute sous VB et rencontre un petit "soucis".
Au sein d'un fichier texte, je souhaiterai ecrire une ligne vide à la suite
de la dernière ligne du fichier (un retour charriot en fait).
J'ai tenté de ré écrire le fichier texte en mettant en tampon (buffer) le
fichier initial puis en re écrivant le fichier final en l'alimentant du
contenu du buffer + 1 ligne vierge. Mais ca marche pas !
J'imagine pourtant que ce ne doit pas être très compliqué. Quelqu'un
pourrait il me donner un exemple ?
1000 mercis à vous.
Pourquoi ne pas utiliser la syntaxe suivante (avec les déclarations ad-hoc) :
ff = freefile Open NomFich For Binary As ff p = LOF(ff) fich = Input(p, ff) 'fich contient tout le fichier Close ff
Cela évite de créer un buffer. De plus cela marche aussi en mode Input.
Eric
ng
Oui mais c'est plus lent qu'un bon vieux get avec un buffer bien fait :
Dim k As Integer, strBuffer As String k = FreeFile Open "c:fichier.txt" For Binary As #k '//Préparation du buffer strBuffer = String$(LOF(k), vbNullChar) '//remplissage à partir du fichier Get #k, , strBuffer Close #k
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Barsalou wrote:
Bonjour
Pourquoi ne pas utiliser la syntaxe suivante (avec les déclarations ad-hoc)
ff = freefile Open NomFich For Binary As ff p = LOF(ff) fich = Input(p, ff) 'fich contient tout le fichier Close ff
Cela évite de créer un buffer. De plus cela marche aussi en mode Input.
Eric
Oui mais c'est plus lent qu'un bon vieux get avec un buffer bien fait :
Dim k As Integer, strBuffer As String
k = FreeFile
Open "c:fichier.txt" For Binary As #k
'//Préparation du buffer
strBuffer = String$(LOF(k), vbNullChar)
'//remplissage à partir du fichier
Get #k, , strBuffer
Close #k
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
Barsalou wrote:
Bonjour
Pourquoi ne pas utiliser la syntaxe suivante (avec les déclarations
ad-hoc)
ff = freefile
Open NomFich For Binary As ff
p = LOF(ff)
fich = Input(p, ff) 'fich contient tout le fichier
Close ff
Cela évite de créer un buffer.
De plus cela marche aussi en mode Input.
Oui mais c'est plus lent qu'un bon vieux get avec un buffer bien fait :
Dim k As Integer, strBuffer As String k = FreeFile Open "c:fichier.txt" For Binary As #k '//Préparation du buffer strBuffer = String$(LOF(k), vbNullChar) '//remplissage à partir du fichier Get #k, , strBuffer Close #k
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Barsalou wrote:
Bonjour
Pourquoi ne pas utiliser la syntaxe suivante (avec les déclarations ad-hoc)
ff = freefile Open NomFich For Binary As ff p = LOF(ff) fich = Input(p, ff) 'fich contient tout le fichier Close ff
Cela évite de créer un buffer. De plus cela marche aussi en mode Input.
Eric
Barsalou
Salut
Effectivement Get est près de 20 fois plus rapide ! Je viens de faire le test et je demande le raison de cette énorme différence.
En tout cas je suis content de le savoir !
Salut
Effectivement Get est près de 20 fois plus rapide !
Je viens de faire le test et je demande le raison de cette énorme
différence.
Effectivement Get est près de 20 fois plus rapide ! Je viens de faire le test et je demande le raison de cette énorme différence.
En tout cas je suis content de le savoir !
ng
Salut,
Parce qu'input travaille en texte pour du texte à la base, ce qui est plus lent que de travailler en binaire.
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Barsalou wrote:
Salut
Effectivement Get est près de 20 fois plus rapide ! Je viens de faire le test et je demande le raison de cette énorme différence.
En tout cas je suis content de le savoir !
Salut,
Parce qu'input travaille en texte pour du texte à la base, ce qui est plus
lent que de travailler en binaire.
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
Barsalou wrote:
Salut
Effectivement Get est près de 20 fois plus rapide !
Je viens de faire le test et je demande le raison de cette énorme
différence.
Parce qu'input travaille en texte pour du texte à la base, ce qui est plus lent que de travailler en binaire.
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Barsalou wrote:
Salut
Effectivement Get est près de 20 fois plus rapide ! Je viens de faire le test et je demande le raison de cette énorme différence.
En tout cas je suis content de le savoir !
Zoury
> amha, Yannick a voulu parler du temps d'exécution plutôt que de la vitesse ... ce dernier est proportionnel à la taille du fichier, ce qui en
yep .. je viens de me relire et j'ai carrément dit l'inverse de ce que je voulais.. :O)
et VB les concaténations de chaine sont très lente car le système doit recréer une nouvelle chaine en mémoire à chaque fois (il ne modifie pas la chaine actuel).. ce qui fait que plus on concatene de caractère à une chaine plus celle-ci prendra de temps à se créer (car l'espace mémoire à allouer est de plus en plus vaste). C'est pourquoi l'algorithme présenter dans le précédent message sera peut-être rapide au début mais il deviendra très très lent à la longue...
-- Cordialement Yanick Lefebvre MVP pour Visual Basic
> amha, Yannick a voulu parler du temps d'exécution plutôt que de la vitesse
... ce dernier est proportionnel à la taille du fichier, ce qui en
yep .. je viens de me relire et j'ai carrément dit l'inverse de ce que je
voulais.. :O)
et VB les concaténations de chaine sont très lente car le système doit
recréer une nouvelle chaine en mémoire à chaque fois (il ne modifie pas la
chaine actuel).. ce qui fait que plus on concatene de caractère à une chaine
plus celle-ci prendra de temps à se créer (car l'espace mémoire à allouer
est de plus en plus vaste). C'est pourquoi l'algorithme présenter dans le
précédent message sera peut-être rapide au début mais il deviendra très très
lent à la longue...
--
Cordialement
Yanick Lefebvre
MVP pour Visual Basic
> amha, Yannick a voulu parler du temps d'exécution plutôt que de la vitesse ... ce dernier est proportionnel à la taille du fichier, ce qui en
yep .. je viens de me relire et j'ai carrément dit l'inverse de ce que je voulais.. :O)
et VB les concaténations de chaine sont très lente car le système doit recréer une nouvelle chaine en mémoire à chaque fois (il ne modifie pas la chaine actuel).. ce qui fait que plus on concatene de caractère à une chaine plus celle-ci prendra de temps à se créer (car l'espace mémoire à allouer est de plus en plus vaste). C'est pourquoi l'algorithme présenter dans le précédent message sera peut-être rapide au début mais il deviendra très très lent à la longue...
-- Cordialement Yanick Lefebvre MVP pour Visual Basic
