Dans un Richtextbox je mets un fichier TXT de 120 colonnes
et active les ascenseurs verticaux et horizontaux. Mais seul l'ascenseur
vertical se pr¨¦sente,
et jamais l'ascenseur horizontal alors que la largeur du fichier affich¨¦
depasse la largeur du Richtexbox.
Sauriez vous me dire comment activer cet ascenseur horizontal dans un
Richtextbox ?
De plus, j'ai voulu utiliser la fonction standart de Recherche(avec ou sans
casse, vers le haut, vers le bas)
que j'ai recuperee dans les divers sites, la recherche fonctionne tres bien
pour les fichiers de petite taille,
mais est beaucoup trop longue a "video-inverser" la chaine trouvee pour un
fichier de 5 Mo environ.
Disposez-vous d'un outil de recherche de texte pour un Richtextbox qui soit
assez rapide pour un gros fichier ?
Il semblerait que ça fasse environ 12 années tes 5 Mo de 10 lignes de 120 caractères par jour...
Des fichiers de texte de 5 à 50 Mo, on en manipule tous les jours, c'est d'usage courant en informatique. Peut être pas dans ton informatique, mais pour le reste du monde, oui.
Déjà l'ascenseur horizontal, quand ce n'est pas formaté, ce qui est le cas, ça n'a pas d'utilité, le vertical suffit, au contraire d'ailleurs, il est plus confortable de pouvoir redimensionner son éditeur de texte, le texte passe à la ligne et la lecture continue.
Mais non - Quand on lit des fichiers de log, ce qui est le cas ici, on ne veut surtout pas de retours à la ligne...
Pourquoi ne pas mettre depuis l'application le fichier en ouverture dans Word, qui possède une recherche élaborée (Word lit le RTF qui est un format proche de Word).
Peut etre parce que som programme est destiné à être déployé sur des dizaines ou des centaines de machines, non munies de Word?
Sinon, voir la possibilité de le couper selon plusieurs périodes de dates.
Mais non. Quand on cherche dans des logs, on a autre chose à faire que du saucissonage.
Est-ce que les mots-clefs intéressant sont nombreux, parce qu'on peut envisager une indexation dans certain cas ?
L'indexation est inutile ici : la recherche se fait en 100 ms dans un fichier de 6 Mo, pourquoi voudrait on indexer?
Il semblerait que ça fasse environ 12 années tes 5 Mo de 10 lignes
de 120 caractères par jour...
Des fichiers de texte de 5 à 50 Mo, on en manipule tous les jours, c'est
d'usage courant en informatique. Peut être pas dans ton informatique,
mais pour le reste du monde, oui.
Déjà l'ascenseur horizontal, quand ce n'est pas formaté, ce qui
est le cas, ça n'a pas d'utilité, le vertical suffit, au contraire
d'ailleurs, il est plus confortable de pouvoir redimensionner son
éditeur de texte, le texte passe à la ligne et la lecture continue.
Mais non - Quand on lit des fichiers de log, ce qui est le cas ici,
on ne veut surtout pas de retours à la ligne...
Pourquoi ne pas mettre depuis l'application le fichier en
ouverture dans Word, qui possède une recherche élaborée (Word lit le
RTF qui est un format proche de Word).
Peut etre parce que som programme est destiné à être déployé sur des
dizaines ou des centaines de machines, non munies de Word?
Sinon, voir la possibilité de le couper selon plusieurs périodes de
dates.
Mais non. Quand on cherche dans des logs, on a autre chose à faire que
du saucissonage.
Est-ce que les mots-clefs intéressant sont nombreux, parce qu'on
peut envisager une indexation dans certain cas ?
L'indexation est inutile ici : la recherche se fait en 100 ms dans un
fichier de 6 Mo, pourquoi voudrait on indexer?
Il semblerait que ça fasse environ 12 années tes 5 Mo de 10 lignes de 120 caractères par jour...
Des fichiers de texte de 5 à 50 Mo, on en manipule tous les jours, c'est d'usage courant en informatique. Peut être pas dans ton informatique, mais pour le reste du monde, oui.
Déjà l'ascenseur horizontal, quand ce n'est pas formaté, ce qui est le cas, ça n'a pas d'utilité, le vertical suffit, au contraire d'ailleurs, il est plus confortable de pouvoir redimensionner son éditeur de texte, le texte passe à la ligne et la lecture continue.
Mais non - Quand on lit des fichiers de log, ce qui est le cas ici, on ne veut surtout pas de retours à la ligne...
Pourquoi ne pas mettre depuis l'application le fichier en ouverture dans Word, qui possède une recherche élaborée (Word lit le RTF qui est un format proche de Word).
Peut etre parce que som programme est destiné à être déployé sur des dizaines ou des centaines de machines, non munies de Word?
Sinon, voir la possibilité de le couper selon plusieurs périodes de dates.
Mais non. Quand on cherche dans des logs, on a autre chose à faire que du saucissonage.
Est-ce que les mots-clefs intéressant sont nombreux, parce qu'on peut envisager une indexation dans certain cas ?
L'indexation est inutile ici : la recherche se fait en 100 ms dans un fichier de 6 Mo, pourquoi voudrait on indexer?
Tu as dû lire trop vite la réponse de Rosalie à mes questions :
- C'est borné entre une date et une fin de ligne avec ascii 13+10
Et moi je trouve au contraire que c'est bien mieux, car si tu ne sais pas où commence "l'article ?" à remonter, ni ou il fini, celui du mot recherché, tu fais quoi ? Tu ne peux pas extraire sans autre recherche la journée considérée, mais seulement positionner par exemple en début de page le mot recherché et sa suite...
Pour ce qui de ne pas borner un fichier par des retours à la ligne, c'est peut être bon pour un fichier de datas pures, mais pas pour la lecture, car on peut avoir besoin de remonter juste une information, et pour cette raison il faut qu'elle soit cadrée. On peut aussi aller à la ligne ou faire un saut de ligne dans le cadre de la présentation à la lecture humaine. Pour ma part, pour ce type de recherche, s'il n'y a pas trop de pertes en vide, je structure en blocs, ainsi on saute rapidement de boc en bloc, recherchant la date (agenda).
Et si tu avais encore lu tout aussi bien, tu verrais que Rosalie dans sa question initiale ne parle pas d'un fichier LOG (qui est un fichier texte), mais d'un fichier TXT, donc pas LOG ( 22/02/2010 : 18h41 ) !
Quant à "mon informatique", c'est celle des logiciels utilitaires et ludiques "statiques", toutefois tu te trompes, il m'est arrivé de faire des fichier de presque 20 Mo, à cause des photos et son mp3, mais évidemment ce n'était pas du texte à afficher puis à lire.
In fine, la solution de "at" du 8/03/2010 est en l'espèce bonne, c'est celle de lire en RAM, mais ça ne saurait être la panacée universelle, car on ne peut pas sans cesse occuper la RAM, qui fait 4 Go en standard actuel, mais hélas l'OS en prend une part non négligeable, alors une application qui va lancer 5 Mo en RAM n'a aucun incidence, c'est pourquoi je pense que c'est la bonne solution, toutefois si tu mets 50 Mo 10 fois en RAM des fichiers issus d'applications diverses et généralisées, tu va finir par ralentir ton ordinateur (comme les programmes résidents en fait).Ainsi c'est a priori la solution ici, mais pas la solution en générale.
Mes respects chef ;o) - Logiciels, romans, contacts : http://irolog.free.fr _______________________ . .
"Jean-marc" a écrit dans le message de news:4b9568db$0$2878$
LE TROLL wrote:
Bonsoir,
Hello,
Il semblerait que ça fasse environ 12 années tes 5 Mo de 10 lignes de 120 caractères par jour...
Des fichiers de texte de 5 à 50 Mo, on en manipule tous les jours, c'est d'usage courant en informatique. Peut être pas dans ton informatique, mais pour le reste du monde, oui.
Déjà l'ascenseur horizontal, quand ce n'est pas formaté, ce qui est le cas, ça n'a pas d'utilité, le vertical suffit, au contraire d'ailleurs, il est plus confortable de pouvoir redimensionner son éditeur de texte, le texte passe à la ligne et la lecture continue.
Mais non - Quand on lit des fichiers de log, ce qui est le cas ici, on ne veut surtout pas de retours à la ligne...
> Pourquoi ne pas mettre depuis l'application le fichier en
ouverture dans Word, qui possède une recherche élaborée (Word lit le RTF qui est un format proche de Word).
Peut etre parce que som programme est destiné à être déployé sur des dizaines ou des centaines de machines, non munies de Word?
Sinon, voir la possibilité de le couper selon plusieurs périodes de dates.
Mais non. Quand on cherche dans des logs, on a autre chose à faire que du saucissonage.
Est-ce que les mots-clefs intéressant sont nombreux, parce qu'on peut envisager une indexation dans certain cas ?
L'indexation est inutile ici : la recherche se fait en 100 ms dans un fichier de 6 Mo, pourquoi voudrait on indexer?
Tu as dû lire trop vite la réponse de Rosalie à mes questions :
- C'est borné entre une date et une fin de ligne avec ascii 13+10
Et moi je trouve au contraire que c'est bien mieux, car si tu ne sais
pas où commence "l'article ?" à remonter, ni ou il fini, celui du mot
recherché, tu fais quoi ? Tu ne peux pas extraire sans autre recherche la
journée considérée, mais seulement positionner par exemple en début de page
le mot recherché et sa suite...
Pour ce qui de ne pas borner un fichier par des retours à la ligne,
c'est peut être bon pour un fichier de datas pures, mais pas pour la
lecture, car on peut avoir besoin de remonter juste une information, et pour
cette raison il faut qu'elle soit cadrée. On peut aussi aller à la ligne ou
faire un saut de ligne dans le cadre de la présentation à la lecture
humaine.
Pour ma part, pour ce type de recherche, s'il n'y a pas trop de pertes en
vide, je structure en blocs, ainsi on saute rapidement de boc en bloc,
recherchant la date (agenda).
Et si tu avais encore lu tout aussi bien, tu verrais que Rosalie dans sa
question initiale ne parle pas d'un fichier LOG (qui est un fichier texte),
mais d'un fichier TXT, donc pas LOG ( 22/02/2010 : 18h41 ) !
Quant à "mon informatique", c'est celle des logiciels utilitaires et
ludiques "statiques", toutefois tu te trompes, il m'est arrivé de faire des
fichier de presque 20 Mo, à cause des photos et son mp3, mais évidemment ce
n'était pas du texte à afficher puis à lire.
In fine, la solution de "at" du 8/03/2010 est en l'espèce bonne, c'est
celle de lire en RAM, mais ça ne saurait être la panacée universelle, car on
ne peut pas sans cesse occuper la RAM, qui fait 4 Go en standard actuel,
mais hélas l'OS en prend une part non négligeable, alors une application qui
va lancer 5 Mo en RAM n'a aucun incidence, c'est pourquoi je pense que c'est
la bonne solution, toutefois si tu mets 50 Mo 10 fois en RAM des fichiers
issus d'applications diverses et généralisées, tu va finir par ralentir ton
ordinateur (comme les programmes résidents en fait).Ainsi c'est a priori la
solution ici, mais pas la solution en générale.
Mes respects chef ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________
.
.
"Jean-marc" <jm@nowhere.invalid> a écrit dans le message de
news:4b9568db$0$2878$ba620e4c@news.skynet.be...
LE TROLL wrote:
Bonsoir,
Hello,
Il semblerait que ça fasse environ 12 années tes 5 Mo de 10 lignes
de 120 caractères par jour...
Des fichiers de texte de 5 à 50 Mo, on en manipule tous les jours, c'est
d'usage courant en informatique. Peut être pas dans ton informatique,
mais pour le reste du monde, oui.
Déjà l'ascenseur horizontal, quand ce n'est pas formaté, ce qui
est le cas, ça n'a pas d'utilité, le vertical suffit, au contraire
d'ailleurs, il est plus confortable de pouvoir redimensionner son
éditeur de texte, le texte passe à la ligne et la lecture continue.
Mais non - Quand on lit des fichiers de log, ce qui est le cas ici,
on ne veut surtout pas de retours à la ligne...
> Pourquoi ne pas mettre depuis l'application le fichier en
ouverture dans Word, qui possède une recherche élaborée (Word lit le
RTF qui est un format proche de Word).
Peut etre parce que som programme est destiné à être déployé sur des
dizaines ou des centaines de machines, non munies de Word?
Sinon, voir la possibilité de le couper selon plusieurs périodes de
dates.
Mais non. Quand on cherche dans des logs, on a autre chose à faire que
du saucissonage.
Est-ce que les mots-clefs intéressant sont nombreux, parce qu'on
peut envisager une indexation dans certain cas ?
L'indexation est inutile ici : la recherche se fait en 100 ms dans un
fichier de 6 Mo, pourquoi voudrait on indexer?
Tu as dû lire trop vite la réponse de Rosalie à mes questions :
- C'est borné entre une date et une fin de ligne avec ascii 13+10
Et moi je trouve au contraire que c'est bien mieux, car si tu ne sais pas où commence "l'article ?" à remonter, ni ou il fini, celui du mot recherché, tu fais quoi ? Tu ne peux pas extraire sans autre recherche la journée considérée, mais seulement positionner par exemple en début de page le mot recherché et sa suite...
Pour ce qui de ne pas borner un fichier par des retours à la ligne, c'est peut être bon pour un fichier de datas pures, mais pas pour la lecture, car on peut avoir besoin de remonter juste une information, et pour cette raison il faut qu'elle soit cadrée. On peut aussi aller à la ligne ou faire un saut de ligne dans le cadre de la présentation à la lecture humaine. Pour ma part, pour ce type de recherche, s'il n'y a pas trop de pertes en vide, je structure en blocs, ainsi on saute rapidement de boc en bloc, recherchant la date (agenda).
Et si tu avais encore lu tout aussi bien, tu verrais que Rosalie dans sa question initiale ne parle pas d'un fichier LOG (qui est un fichier texte), mais d'un fichier TXT, donc pas LOG ( 22/02/2010 : 18h41 ) !
Quant à "mon informatique", c'est celle des logiciels utilitaires et ludiques "statiques", toutefois tu te trompes, il m'est arrivé de faire des fichier de presque 20 Mo, à cause des photos et son mp3, mais évidemment ce n'était pas du texte à afficher puis à lire.
In fine, la solution de "at" du 8/03/2010 est en l'espèce bonne, c'est celle de lire en RAM, mais ça ne saurait être la panacée universelle, car on ne peut pas sans cesse occuper la RAM, qui fait 4 Go en standard actuel, mais hélas l'OS en prend une part non négligeable, alors une application qui va lancer 5 Mo en RAM n'a aucun incidence, c'est pourquoi je pense que c'est la bonne solution, toutefois si tu mets 50 Mo 10 fois en RAM des fichiers issus d'applications diverses et généralisées, tu va finir par ralentir ton ordinateur (comme les programmes résidents en fait).Ainsi c'est a priori la solution ici, mais pas la solution en générale.
Mes respects chef ;o) - Logiciels, romans, contacts : http://irolog.free.fr _______________________ . .
"Jean-marc" a écrit dans le message de news:4b9568db$0$2878$
LE TROLL wrote:
Bonsoir,
Hello,
Il semblerait que ça fasse environ 12 années tes 5 Mo de 10 lignes de 120 caractères par jour...
Des fichiers de texte de 5 à 50 Mo, on en manipule tous les jours, c'est d'usage courant en informatique. Peut être pas dans ton informatique, mais pour le reste du monde, oui.
Déjà l'ascenseur horizontal, quand ce n'est pas formaté, ce qui est le cas, ça n'a pas d'utilité, le vertical suffit, au contraire d'ailleurs, il est plus confortable de pouvoir redimensionner son éditeur de texte, le texte passe à la ligne et la lecture continue.
Mais non - Quand on lit des fichiers de log, ce qui est le cas ici, on ne veut surtout pas de retours à la ligne...
> Pourquoi ne pas mettre depuis l'application le fichier en
ouverture dans Word, qui possède une recherche élaborée (Word lit le RTF qui est un format proche de Word).
Peut etre parce que som programme est destiné à être déployé sur des dizaines ou des centaines de machines, non munies de Word?
Sinon, voir la possibilité de le couper selon plusieurs périodes de dates.
Mais non. Quand on cherche dans des logs, on a autre chose à faire que du saucissonage.
Est-ce que les mots-clefs intéressant sont nombreux, parce qu'on peut envisager une indexation dans certain cas ?
L'indexation est inutile ici : la recherche se fait en 100 ms dans un fichier de 6 Mo, pourquoi voudrait on indexer?
N'y avait-il pas un truc qui avalait tout le fichier, genre :
Dim p As Long Dim buffer As String Dim r As String Dim x As Long ChDrive App.Path ChDir App.Path p = FreeFile Open "f.txt" For Binary As p buffer = Space$(LOF(p)) Get #p, , buffer Close #p ' r = InStr(x, buffer, cherche, 1) If r <> 0 Then MsgBox "ok"
"at" a écrit dans le message de news:4b955746$0$17883$
Rosalie Mignon a exprimé avec précision :
Bonjour
Erreur de ma part, il ne s'agit pas de tri mais de filtre.
Dans un fichier .TXT , de caracteres quelconques mais formate "date-heure texte_libre" et ce pourr chaque ligne , de longueur de ligne quelconque, borne par crlf, avec un nombre de ligne inconnu au depart, d'une taille de 5Mo environ. Le but, a l'origine etait d'extraire et d'afficher que des lignes comportant un texte precis, ligne correspondant a 08/03/2010 par exemple, mais dont je savais qu'elles seraient en nombre tres restreint, puisque par jour il n'y a qu'une dizaines de lignes. Donc pour moi, un Textbox etait suffisant .
Depuis, les utilisateurs ne s'interressent plus seulement a la date, mais aussi au texte libre. Je dois donc leur afficher le fichier au complet, pour qu'ils puissent a sa lecture determiner ce qui pourraient les interesser, proposer un masque de saisie pour les chaines a extraire, et afficher les X lignes correspondantes a l'ecran.
Alors effectivement, j'ai choisi la facilite en prenant le Richtextbox pour afficher le fichier, je n'ai donc pas a gerer le contenu du Textbox en fonction des fleches de deplacement ou des ascenseurs, et ce quelquesoit le nombre de lignes a afficher( pas de taille limite).
J'espere avoir ete plus claire cette fois ci, Pour moi, le probleme qui subsiste, c'est la recheche d'occurence dans le fichier, et effectivement, le Richtextbox me pose probleme. Avec une recherche dans le tableau en memoire, et affichage du Textbox en consequence, on pourrait arriver a un resultat plus efficace en terme de temps.
De toute façon 5 mo c'est peanuts. J'ai eu programmer un soft de recherche de fichiers avec option de recherche de texte dans les fichiers et la solution utilisée et le chargement du fichier par morceau dans un buffer et recherche avec l'instruction "InStr", ça se fait très rapidement. Le fichier est ouvert en mode "For Binary" avec à suivre dans un do loop ave un get #1, , bufferx ...
Exemple
Dim bufferx As String * 1024 Open "c:fichier.txt" For Binary As 1
do while not eof(1) get #1, , bufferx
getag = InStr(1, bufferx, chaine_recherche, 1) if gettag then msgbox "trouvé à la position " & Loc(1) : Loop Close
Je ne connais pas la structure de ton fichier, donc pour extraire les données relatives à la recherche à toi de jouer! L'exemple ci-dessus est donné de façon brut, faut le re-travailler mais je pense que c'est une piste à étudier.
Bonjour Messire AT,
N'y avait-il pas un truc qui avalait tout le fichier, genre :
Dim p As Long
Dim buffer As String
Dim r As String
Dim x As Long
ChDrive App.Path
ChDir App.Path
p = FreeFile
Open "f.txt" For Binary As p
buffer = Space$(LOF(p))
Get #p, , buffer
Close #p
'
r = InStr(x, buffer, cherche, 1)
If r <> 0 Then MsgBox "ok"
"at" <at@noemail.fr> a écrit dans le message de
news:4b955746$0$17883$ba4acef3@reader.news.orange.fr...
Rosalie Mignon a exprimé avec précision :
Bonjour
Erreur de ma part, il ne s'agit pas de tri mais de filtre.
Dans un fichier .TXT , de caracteres quelconques mais formate
"date-heure texte_libre" et ce pourr chaque ligne , de longueur de ligne
quelconque, borne par crlf, avec un nombre de ligne inconnu au depart,
d'une taille de 5Mo environ.
Le but, a l'origine etait d'extraire et d'afficher que des lignes
comportant un texte precis, ligne correspondant a 08/03/2010 par exemple,
mais dont je savais qu'elles seraient en nombre tres restreint, puisque
par jour il n'y a qu'une dizaines de lignes.
Donc pour moi, un Textbox etait suffisant .
Depuis, les utilisateurs ne s'interressent plus seulement a la date, mais
aussi au texte libre. Je dois donc leur afficher le fichier au complet,
pour qu'ils puissent a sa lecture
determiner ce qui pourraient les interesser, proposer un masque de saisie
pour les chaines a extraire, et afficher les X lignes correspondantes a
l'ecran.
Alors effectivement, j'ai choisi la facilite en prenant le Richtextbox
pour afficher le fichier, je n'ai donc pas a gerer le contenu du Textbox
en fonction des fleches de deplacement ou des ascenseurs, et ce
quelquesoit le nombre de lignes a afficher( pas de taille limite).
J'espere avoir ete plus claire cette fois ci,
Pour moi, le probleme qui subsiste, c'est la recheche d'occurence dans le
fichier, et effectivement, le Richtextbox me pose probleme.
Avec une recherche dans le tableau en memoire, et affichage du Textbox en
consequence, on pourrait arriver a un resultat plus efficace en terme de
temps.
De toute façon 5 mo c'est peanuts. J'ai eu programmer un soft de recherche
de fichiers avec option de recherche de texte dans les fichiers et la
solution utilisée et le chargement du fichier par morceau dans un buffer
et recherche avec l'instruction "InStr", ça se fait très rapidement.
Le fichier est ouvert en mode "For Binary" avec à suivre dans un do loop
ave un get #1, , bufferx ...
Exemple
Dim bufferx As String * 1024
Open "c:fichier.txt" For Binary As 1
do while not eof(1)
get #1, , bufferx
getag = InStr(1, bufferx, chaine_recherche, 1)
if gettag then msgbox "trouvé à la position " & Loc(1) :
Loop
Close
Je ne connais pas la structure de ton fichier, donc pour extraire les
données relatives à la recherche à toi de jouer!
L'exemple ci-dessus est donné de façon brut, faut le re-travailler mais je
pense que c'est une piste à étudier.
N'y avait-il pas un truc qui avalait tout le fichier, genre :
Dim p As Long Dim buffer As String Dim r As String Dim x As Long ChDrive App.Path ChDir App.Path p = FreeFile Open "f.txt" For Binary As p buffer = Space$(LOF(p)) Get #p, , buffer Close #p ' r = InStr(x, buffer, cherche, 1) If r <> 0 Then MsgBox "ok"
"at" a écrit dans le message de news:4b955746$0$17883$
Rosalie Mignon a exprimé avec précision :
Bonjour
Erreur de ma part, il ne s'agit pas de tri mais de filtre.
Dans un fichier .TXT , de caracteres quelconques mais formate "date-heure texte_libre" et ce pourr chaque ligne , de longueur de ligne quelconque, borne par crlf, avec un nombre de ligne inconnu au depart, d'une taille de 5Mo environ. Le but, a l'origine etait d'extraire et d'afficher que des lignes comportant un texte precis, ligne correspondant a 08/03/2010 par exemple, mais dont je savais qu'elles seraient en nombre tres restreint, puisque par jour il n'y a qu'une dizaines de lignes. Donc pour moi, un Textbox etait suffisant .
Depuis, les utilisateurs ne s'interressent plus seulement a la date, mais aussi au texte libre. Je dois donc leur afficher le fichier au complet, pour qu'ils puissent a sa lecture determiner ce qui pourraient les interesser, proposer un masque de saisie pour les chaines a extraire, et afficher les X lignes correspondantes a l'ecran.
Alors effectivement, j'ai choisi la facilite en prenant le Richtextbox pour afficher le fichier, je n'ai donc pas a gerer le contenu du Textbox en fonction des fleches de deplacement ou des ascenseurs, et ce quelquesoit le nombre de lignes a afficher( pas de taille limite).
J'espere avoir ete plus claire cette fois ci, Pour moi, le probleme qui subsiste, c'est la recheche d'occurence dans le fichier, et effectivement, le Richtextbox me pose probleme. Avec une recherche dans le tableau en memoire, et affichage du Textbox en consequence, on pourrait arriver a un resultat plus efficace en terme de temps.
De toute façon 5 mo c'est peanuts. J'ai eu programmer un soft de recherche de fichiers avec option de recherche de texte dans les fichiers et la solution utilisée et le chargement du fichier par morceau dans un buffer et recherche avec l'instruction "InStr", ça se fait très rapidement. Le fichier est ouvert en mode "For Binary" avec à suivre dans un do loop ave un get #1, , bufferx ...
Exemple
Dim bufferx As String * 1024 Open "c:fichier.txt" For Binary As 1
do while not eof(1) get #1, , bufferx
getag = InStr(1, bufferx, chaine_recherche, 1) if gettag then msgbox "trouvé à la position " & Loc(1) : Loop Close
Je ne connais pas la structure de ton fichier, donc pour extraire les données relatives à la recherche à toi de jouer! L'exemple ci-dessus est donné de façon brut, faut le re-travailler mais je pense que c'est une piste à étudier.
at
LE TROLL a émis l'idée suivante :
Bonjour Messire AT,
N'y avait-il pas un truc qui avalait tout le fichier, genre :
Dim p As Long Dim buffer As String Dim r As String Dim x As Long ChDrive App.Path ChDir App.Path p = FreeFile Open "f.txt" For Binary As p buffer = Space$(LOF(p)) Get #p, , buffer Close #p ' r = InStr(x, buffer, cherche, 1) If r <> 0 Then MsgBox "ok"
Ok mais un fichier de plusieurs Go, je préfère largement la technique du découpage, ça évite de bloquer un processus.
LE TROLL a émis l'idée suivante :
Bonjour Messire AT,
N'y avait-il pas un truc qui avalait tout le fichier, genre :
Dim p As Long
Dim buffer As String
Dim r As String
Dim x As Long
ChDrive App.Path
ChDir App.Path
p = FreeFile
Open "f.txt" For Binary As p
buffer = Space$(LOF(p))
Get #p, , buffer
Close #p
'
r = InStr(x, buffer, cherche, 1)
If r <> 0 Then MsgBox "ok"
Ok mais un fichier de plusieurs Go, je préfère largement la technique
du découpage, ça évite de bloquer un processus.
N'y avait-il pas un truc qui avalait tout le fichier, genre :
Dim p As Long Dim buffer As String Dim r As String Dim x As Long ChDrive App.Path ChDir App.Path p = FreeFile Open "f.txt" For Binary As p buffer = Space$(LOF(p)) Get #p, , buffer Close #p ' r = InStr(x, buffer, cherche, 1) If r <> 0 Then MsgBox "ok"
Ok mais un fichier de plusieurs Go, je préfère largement la technique du découpage, ça évite de bloquer un processus.
at
at a exposé le 09/03/2010 :
Ok mais un fichier de plusieurs Go, je préfère largement la technique du découpage, ça évite de bloquer un processus.
Lire Mo.
at a exposé le 09/03/2010 :
Ok mais un fichier de plusieurs Go, je préfère largement la technique du
découpage, ça évite de bloquer un processus.
Ok mais un fichier de plusieurs Go, je préfère largement la technique du découpage, ça évite de bloquer un processus.
Lire Mo.
Jean-marc
LE TROLL wrote:
Chef,
Et si tu avais encore lu tout aussi bien, tu verrais que Rosalie dans sa question initiale ne parle pas d'un fichier LOG (qui est un fichier texte), mais d'un fichier TXT, donc pas LOG ( 22/02/2010 : 18h41 ) !
Je renonce :-(
un "fichier de log", c'est un fichier qu'on utilise pour "logger" des choses, des évènements. C'est un terme générique. Quand Rosalie décrit un fichier qui grossit d'une dizaine de lignes par jour, qui contient des lignes qui commencent par une date/heure, crois en mon expérience, c'est un fichier de log.
L'extension (.log, .txt) n'a rien à voir ici! On est libre de choisir l'extension que l'on veut.
Et si tu avais encore lu tout aussi bien, tu verrais que Rosalie
dans sa question initiale ne parle pas d'un fichier LOG (qui est un
fichier texte), mais d'un fichier TXT, donc pas LOG ( 22/02/2010 :
18h41 ) !
Je renonce :-(
un "fichier de log", c'est un fichier qu'on utilise pour "logger"
des choses, des évènements. C'est un terme générique.
Quand Rosalie décrit un fichier qui grossit d'une dizaine de lignes
par jour, qui contient des lignes qui commencent par une date/heure,
crois en mon expérience, c'est un fichier de log.
L'extension (.log, .txt) n'a rien à voir ici! On est libre de choisir
l'extension que l'on veut.
Et si tu avais encore lu tout aussi bien, tu verrais que Rosalie dans sa question initiale ne parle pas d'un fichier LOG (qui est un fichier texte), mais d'un fichier TXT, donc pas LOG ( 22/02/2010 : 18h41 ) !
Je renonce :-(
un "fichier de log", c'est un fichier qu'on utilise pour "logger" des choses, des évènements. C'est un terme générique. Quand Rosalie décrit un fichier qui grossit d'une dizaine de lignes par jour, qui contient des lignes qui commencent par une date/heure, crois en mon expérience, c'est un fichier de log.
L'extension (.log, .txt) n'a rien à voir ici! On est libre de choisir l'extension que l'on veut.