J'ai un fichier .txt dans lequel est inscrit plusieurs=20
lignes de texte. Avec du code VB6, je voudrais pouvoir=20
remplacer dans ce fichier une chaine de caract=E8res par une=20
autre (par ex : remplacer la chaine 01/01/1999 par=20
01/01/2000) sachant que cete chaine peut se trouver=20
n'importe o=F9 dans le fichier.
J'ai oublié de dire que ton exemple ne fonctionnait pas....
Open "C:Documents and SettingsPierreMes documentstoto.txt" For Binary Access Read Write As *fd* Close *FFN* ' Ferme le fichier
il faut écrire "Close fd"
Un copié-collé de ton code est la cause de cette erreur.
François Picalausa
Bonjour/soir,
Il y a bien une solution qui consiste à tronquer le fichier via SetEndOfFile. Tu ouvre ton fichier via APIs puis les opérations lire, écrire et tronquer se succèdent.
Révise ton binary et tu sauras que si les données écrites sont de tailles inférieures aux données déjà présentes, la taille du fichier n'est pas pour autant tronquée.
C'est nul ça niveau performance. Fin bon y'a pas mieux à c'kil parait :-(. Et certains disent même que c'est une limite de l'OS... Donc logiquement en C++ par exemple, il faut travailler de la même façon... J'vais me renseigner, car ça me parrait vraiment bourrain comme méthode.
Fin non ça cloche cette méthode. Parce que au moment où tu recrées ton fichier, tu dois commencer à recopier les droits qu'il y avait sur ton ancien fichier... Sinon tu perds tous les droits que tu avais mis dessus, car ceux-ci sont remplacés par les droits par défauts (càd en général ceux de l'objet parent).
Bonjour/soir,
Il y a bien une solution qui consiste à tronquer le fichier via
SetEndOfFile.
Tu ouvre ton fichier via APIs puis les opérations lire, écrire et tronquer
se succèdent.
"Pierre Alexis" <alexispierre@hotmail.com> a écrit dans le message de
news:uSNe7xPhDHA.1952@TK2MSFTNGP12.phx.gbl
Salut François,
Tu as écrit :
Révise ton binary et tu sauras que si les données écrites sont de
tailles inférieures aux données déjà présentes, la taille du fichier
n'est pas pour autant tronquée.
C'est nul ça niveau performance. Fin bon y'a pas mieux à c'kil parait
:-(. Et certains disent même que c'est une limite de l'OS... Donc
logiquement en C++ par exemple, il faut travailler de la même
façon... J'vais me renseigner, car ça me parrait vraiment bourrain
comme méthode.
Fin non ça cloche cette méthode. Parce que au moment où tu recrées ton
fichier, tu dois commencer à recopier les droits qu'il y avait sur
ton ancien fichier... Sinon tu perds tous les droits que tu avais mis
dessus, car ceux-ci sont remplacés par les droits par défauts (càd en
général ceux de l'objet parent).
Il y a bien une solution qui consiste à tronquer le fichier via SetEndOfFile. Tu ouvre ton fichier via APIs puis les opérations lire, écrire et tronquer se succèdent.
Révise ton binary et tu sauras que si les données écrites sont de tailles inférieures aux données déjà présentes, la taille du fichier n'est pas pour autant tronquée.
C'est nul ça niveau performance. Fin bon y'a pas mieux à c'kil parait :-(. Et certains disent même que c'est une limite de l'OS... Donc logiquement en C++ par exemple, il faut travailler de la même façon... J'vais me renseigner, car ça me parrait vraiment bourrain comme méthode.
Fin non ça cloche cette méthode. Parce que au moment où tu recrées ton fichier, tu dois commencer à recopier les droits qu'il y avait sur ton ancien fichier... Sinon tu perds tous les droits que tu avais mis dessus, car ceux-ci sont remplacés par les droits par défauts (càd en général ceux de l'objet parent).
Christophe
Salut vous pouvez en dire plus ?
Pas ce que j'ai le même pb je suis obliger de faire kill avant le open
j'ai une appli exterieur qui genere un fichier texte de taille aleatoire que je consulte ensuite et je me suis aperçu que si je kill pas avant ben c'est comme dit françois il y a des morceaux du précédent qui restent
Christophe Vergon
"François Picalausa" a écrit dans le message de news:
Bonjour/soir,
> ??????????? Tu supprime le fichier pour ensuite le recréer et > l'ouvrir ?!?
Révise ton binary et tu sauras que si les données écrites sont de tailles inférieures aux données déjà présentes, la taille du fichier n'est pas
"Pierre Alexis" a écrit dans le message de news: > Salut François, > > Tu as écrit : > >> Kill "c:toto.txt" >> Open "c:toto.txt" For Binary As FFN >> Put FFN,, strBuffer >> Close FFN > > ??????????? Tu supprime le fichier pour ensuite le recréer et > l'ouvrir ?!? Pourquoi ne pas écrire directement ? Comme ceci : > > Dim fd As Integer, Buffer As String > > fd = FreeFile ' Recupère un file descriptor de libre > > ' Ouvre le fichier > Open "C:Documents and SettingsPierreMes documentstoto.txt" For > Binary Access Read Write As fd > Buffer = String$(LOF(fd), vbNullChar) ' Initalise le buffer > Get fd, , Buffer ' Lit les données dans le buffer > Buffer = Replace(Buffer, "01/01/1999", "01/01/2000") ' Effectue le > remplacement > Put fd, 1, Buffer ' Ecrit les données > Close FFN ' Ferme le fichier
Salut vous pouvez en dire plus ?
Pas ce que j'ai le même pb je suis obliger de faire kill avant le open
j'ai une appli exterieur qui genere un fichier texte de taille aleatoire que
je consulte ensuite et je me suis aperçu que si je kill pas avant ben c'est
comme dit françois il y a des morceaux du précédent qui restent
Christophe Vergon
"François Picalausa" <fpicalausa@chez.com> a écrit dans le message de news:
e4gambPhDHA.1956@TK2MSFTNGP10.phx.gbl...
Bonjour/soir,
> ??????????? Tu supprime le fichier pour ensuite le recréer et
> l'ouvrir ?!?
Révise ton binary et tu sauras que si les données écrites sont de tailles
inférieures aux données déjà présentes, la taille du fichier n'est pas
"Pierre Alexis" <alexispierre@hotmail.com> a écrit dans le message de
news:eZv48hNhDHA.2984@TK2MSFTNGP11.phx.gbl
> Salut François,
>
> Tu as écrit :
>
>> Kill "c:toto.txt"
>> Open "c:toto.txt" For Binary As FFN
>> Put FFN,, strBuffer
>> Close FFN
>
> ??????????? Tu supprime le fichier pour ensuite le recréer et
> l'ouvrir ?!? Pourquoi ne pas écrire directement ? Comme ceci :
>
> Dim fd As Integer, Buffer As String
>
> fd = FreeFile ' Recupère un file descriptor de libre
>
> ' Ouvre le fichier
> Open "C:Documents and SettingsPierreMes documentstoto.txt" For
> Binary Access Read Write As fd
> Buffer = String$(LOF(fd), vbNullChar) ' Initalise le buffer
> Get fd, , Buffer ' Lit les données dans le buffer
> Buffer = Replace(Buffer, "01/01/1999", "01/01/2000") ' Effectue le
> remplacement
> Put fd, 1, Buffer ' Ecrit les données
> Close FFN ' Ferme le fichier
Pas ce que j'ai le même pb je suis obliger de faire kill avant le open
j'ai une appli exterieur qui genere un fichier texte de taille aleatoire que je consulte ensuite et je me suis aperçu que si je kill pas avant ben c'est comme dit françois il y a des morceaux du précédent qui restent
Christophe Vergon
"François Picalausa" a écrit dans le message de news:
Bonjour/soir,
> ??????????? Tu supprime le fichier pour ensuite le recréer et > l'ouvrir ?!?
Révise ton binary et tu sauras que si les données écrites sont de tailles inférieures aux données déjà présentes, la taille du fichier n'est pas
"Pierre Alexis" a écrit dans le message de news: > Salut François, > > Tu as écrit : > >> Kill "c:toto.txt" >> Open "c:toto.txt" For Binary As FFN >> Put FFN,, strBuffer >> Close FFN > > ??????????? Tu supprime le fichier pour ensuite le recréer et > l'ouvrir ?!? Pourquoi ne pas écrire directement ? Comme ceci : > > Dim fd As Integer, Buffer As String > > fd = FreeFile ' Recupère un file descriptor de libre > > ' Ouvre le fichier > Open "C:Documents and SettingsPierreMes documentstoto.txt" For > Binary Access Read Write As fd > Buffer = String$(LOF(fd), vbNullChar) ' Initalise le buffer > Get fd, , Buffer ' Lit les données dans le buffer > Buffer = Replace(Buffer, "01/01/1999", "01/01/2000") ' Effectue le > remplacement > Put fd, 1, Buffer ' Ecrit les données > Close FFN ' Ferme le fichier
