Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic recherche plein texte d'explorer

recherche plein texte d'explorer

16 réponses
Avatar
Francois
Bonjour,

Je souhaiterais utiliser dans un programme la recherche plein texte de MS
Explorer afin de trouver dans une série de fichiers certains mots clé. J'ai
pu arriver à ce résultat par programmation, mais ça prends 10 fois plus de
temps que celle d'Explorer (30s contre 3s...)...
Y a t'il une API à utiliser ou un paramètre à envoyer à Explorer via une
commande Shell de manière à ce que ce soit ce moteur de recherche de Windows
qui soit exécuté ?

Merci.

François
Signaler un problème avec ce contenu

6 réponses

Supprimer
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
1 2
Avatar
Quasimodo
Francois was thinking very hard :
Bonjour

C'est un peu la solution de contournement que je pensais faire :

"....Mais j'ai une autre idée bourin en tête : stocker dans une base access
le contenu texte de tous les documents de la base... Et créer un prog qui
scrute de tps en tps si le contenu de ces fichiers a bougé. => la recherche
plein texte devient alors une simple requête."

Ca confirme cette piste et peut être la bonne solution puisqu'effectivement
je sais dans la base où se trouvent ces fichiers.

Merci

François



re,
attention qu'il existe déjà de tels outils, mais payent (voir : les
sytème d'indexation de windows 2000, SharePoint Portal Server 2003,
...). Aussi, ne faite pas de recopie de vos fichiers dans une db, vous
alourdirez pour rien votre db, sans gagnier en pertinence de recherche.
Votre recherche ne portera jamais sur un mots (celui-ci vous ramenera
trop de documents), par contre si votre recherche se base sur des mots
n'apparaissant que dans un fichier bien précis ou sur des sujets, des
tags ... Ce que je veux dire, c'est de baser votre recherche sur un
subset de données.

@+ Quaz

--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
Avatar
Francois
Bonjour Quasimodo,

Je suis d'accord avec toi, et c'est d'ailleurs ce que fait le reste de
l'application (mots clé, thèmes, sujets...)... et c'est au client de mettre
en place ces informations.
Mais là, c'est justement faire une recherche sur mots divers, non inscrits
dans la liste des mots clé par exemple...
Bon, il est vrai que si je mets le contenu des fichiers, il vaudrait mieux
virer les articles (le, la, les...) et les petits mots sans intérêts (mais,
ou, et, donc, or, ni, car...) pour réduire la taille du texte stocké mais
alors ça prendra plus de temps dans la mise à jour.
Il me faut trouver un juste milieu entre qq chose de moins bourin.

Bon, merci qd même.


"Quasimodo" a écrit dans le message news:

Francois was thinking very hard :
> Bonjour
>
> C'est un peu la solution de contournement que je pensais faire :
>
> "....Mais j'ai une autre idée bourin en tête : stocker dans une base


access
> le contenu texte de tous les documents de la base... Et créer un prog


qui
> scrute de tps en tps si le contenu de ces fichiers a bougé. => la


recherche
> plein texte devient alors une simple requête."
>
> Ca confirme cette piste et peut être la bonne solution


puisqu'effectivement
> je sais dans la base où se trouvent ces fichiers.
>
> Merci
>
> François

re,
attention qu'il existe déjà de tels outils, mais payent (voir : les
sytème d'indexation de windows 2000, SharePoint Portal Server 2003,
...). Aussi, ne faite pas de recopie de vos fichiers dans une db, vous
alourdirez pour rien votre db, sans gagnier en pertinence de recherche.
Votre recherche ne portera jamais sur un mots (celui-ci vous ramenera
trop de documents), par contre si votre recherche se base sur des mots
n'apparaissant que dans un fichier bien précis ou sur des sujets, des
tags ... Ce que je veux dire, c'est de baser votre recherche sur un
subset de données.

@+ Quaz

--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com



Avatar
ng
Salut,

Utilise plutot un get, c'est beaucoup beaucoup plus rapide (Zoury avait fait
des benchmarks) :

Dim k as integer, strBuffer as string
k=FreeFile
Open "c:1.txt" For Binary as #k
strBuffer = String$(LOF(k), vbNullChar)
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/

Francois wrote:
Bonjour,

En fait, je suis sur Access et les docs dont les chemins sont connus
de la base peuvent être sur le réseau et sur des postes distant => Le
langage VB m'irait très bien car si je passais en C, je sens qu'il
faudrait que je gère les chemins réseaux... ce qui n'est pas de la
tarte...
Les documents sont de différents type (Word, XL, PDF, HTML).

Voici des extraits de la fonction d'ouverture :

Fnum = FreeFile

On Error Resume Next
Open Fic For Binary As #Fnum
If Err.Number = 0 Then
On Error GoTo Err_adRecherchePleinTxt

' On récupère la longueur du fichier
LongueurFic = LOF(Fnum)

' On stocke dans une variable le contenu du fichier
PartieFichierLu = Input(LongueurFic, #Fnum)

RechStart = 0
'fermeture du fichier (pas la peine de gaspiller la mémoire)
Close #Fnum

Et voici des extraits de la fonction de recherche (je simplifie car
il a fallut gérer les gros fichiers (découpage en plusieurs parties
de la zone à analyser) et la fonction InStr plantait) :

RechStart = InStr(RechStart + 1, FichierLu, MotACherche,
vbTextCompare)

' Le mot a été trouvé
If RechStart <> 0 Then
...
End If

Voilou

François


Avatar
Quasimodo
Francois formulated on Thursday :
Bonjour Quasimodo,

Je suis d'accord avec toi, et c'est d'ailleurs ce que fait le reste de
l'application (mots clé, thèmes, sujets...)... et c'est au client de mettre
en place ces informations.
Mais là, c'est justement faire une recherche sur mots divers, non inscrits
dans la liste des mots clé par exemple...
Bon, il est vrai que si je mets le contenu des fichiers, il vaudrait mieux
virer les articles (le, la, les...) et les petits mots sans intérêts (mais,
ou, et, donc, or, ni, car...) pour réduire la taille du texte stocké mais
alors ça prendra plus de temps dans la mise à jour.
Il me faut trouver un juste milieu entre qq chose de moins bourin.

Bon, merci qd même.


"Quasimodo" a écrit dans le message news:

Francois was thinking very hard :
Bonjour

C'est un peu la solution de contournement que je pensais faire :

"....Mais j'ai une autre idée bourin en tête : stocker dans une base access
le contenu texte de tous les documents de la base... Et créer un prog qui
scrute de tps en tps si le contenu de ces fichiers a bougé. => la recherche
plein texte devient alors une simple requête."

Ca confirme cette piste et peut être la bonne solution puisqu'effectivement
je sais dans la base où se trouvent ces fichiers.

Merci

François



re,
attention qu'il existe déjà de tels outils, mais payent (voir : les
sytème d'indexation de windows 2000, SharePoint Portal Server 2003,
...). Aussi, ne faite pas de recopie de vos fichiers dans une db, vous
alourdirez pour rien votre db, sans gagnier en pertinence de recherche.
Votre recherche ne portera jamais sur un mots (celui-ci vous ramenera
trop de documents), par contre si votre recherche se base sur des mots
n'apparaissant que dans un fichier bien précis ou sur des sujets, des
tags ... Ce que je veux dire, c'est de baser votre recherche sur un
subset de données.

@+ Quaz

--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com





re,
peut être une piste, c'est de se concentrer sur l'ensemble des
fonctionnalités de l'outils (système de recherche). Je recherche des
infos et je vous envoies cela sur ce même threads.

@+Quaz

--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
Avatar
Jean-Marc
Moi je viens d'essayer Google Desktop: c'est GENIAL !
Je ne fais jamais de pub pour quoi que se soit, mais alors
la, c'est carrément excellent. L'essayer, c'est définitivement
l'adopter!

http://desktop.google.com/


--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."



"Quasimodo" a écrit dans le message de
news:
Francois formulated on Thursday :
> Bonjour Quasimodo,
>
> Je suis d'accord avec toi, et c'est d'ailleurs ce que fait le reste de
> l'application (mots clé, thèmes, sujets...)... et c'est au client de


mettre
> en place ces informations.
> Mais là, c'est justement faire une recherche sur mots divers, non


inscrits
> dans la liste des mots clé par exemple...
> Bon, il est vrai que si je mets le contenu des fichiers, il vaudrait


mieux
> virer les articles (le, la, les...) et les petits mots sans intérêts


(mais,
> ou, et, donc, or, ni, car...) pour réduire la taille du texte stocké


mais
> alors ça prendra plus de temps dans la mise à jour.
> Il me faut trouver un juste milieu entre qq chose de moins bourin.
>
> Bon, merci qd même.
>
>
> "Quasimodo" a écrit dans le message news:
>
>> Francois was thinking very hard :
>>> Bonjour
>>>
>>> C'est un peu la solution de contournement que je pensais faire :
>>>
>>> "....Mais j'ai une autre idée bourin en tête : stocker dans une base


access
>>> le contenu texte de tous les documents de la base... Et créer un prog


qui
>>> scrute de tps en tps si le contenu de ces fichiers a bougé. => la


recherche
>>> plein texte devient alors une simple requête."
>>>
>>> Ca confirme cette piste et peut être la bonne solution


puisqu'effectivement
>>> je sais dans la base où se trouvent ces fichiers.
>>>
>>> Merci
>>>
>>> François
>>
>> re,
>> attention qu'il existe déjà de tels outils, mais payent (voir : les
>> sytème d'indexation de windows 2000, SharePoint Portal Server 2003,
>> ...). Aussi, ne faite pas de recopie de vos fichiers dans une db, vous
>> alourdirez pour rien votre db, sans gagnier en pertinence de recherche.
>> Votre recherche ne portera jamais sur un mots (celui-ci vous ramenera
>> trop de documents), par contre si votre recherche se base sur des mots
>> n'apparaissant que dans un fichier bien précis ou sur des sujets, des
>> tags ... Ce que je veux dire, c'est de baser votre recherche sur un
>> subset de données.
>>
>> @+ Quaz
>>
>> --
>> This is an automatic signature of MesNews.
>> Site : http://mesnews.no-ip.com

re,
peut être une piste, c'est de se concentrer sur l'ensemble des
fonctionnalités de l'outils (système de recherche). Je recherche des
infos et je vous envoies cela sur ce même threads.

@+Quaz

--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com



Avatar
Francois
Merci ng pour l'info,
C'est clair que la rapidité est visuellement plus rapide :-)

En faisant un mix de toutes les méthodes et toutes les infos, je pense que
ça va marcher !
Merci donc aussi aux autres.


"ng" a écrit dans le message news:

Salut,

Utilise plutot un get, c'est beaucoup beaucoup plus rapide (Zoury avait


fait
des benchmarks) :

Dim k as integer, strBuffer as string
k=FreeFile
Open "c:1.txt" For Binary as #k
strBuffer = String$(LOF(k), vbNullChar)
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/

Francois wrote:
> Bonjour,
>
> En fait, je suis sur Access et les docs dont les chemins sont connus
> de la base peuvent être sur le réseau et sur des postes distant => Le
> langage VB m'irait très bien car si je passais en C, je sens qu'il
> faudrait que je gère les chemins réseaux... ce qui n'est pas de la
> tarte...
> Les documents sont de différents type (Word, XL, PDF, HTML).
>
> Voici des extraits de la fonction d'ouverture :
>
> Fnum = FreeFile
>
> On Error Resume Next
> Open Fic For Binary As #Fnum
> If Err.Number = 0 Then
> On Error GoTo Err_adRecherchePleinTxt
>
> ' On récupère la longueur du fichier
> LongueurFic = LOF(Fnum)
>
> ' On stocke dans une variable le contenu du fichier
> PartieFichierLu = Input(LongueurFic, #Fnum)
>
> RechStart = 0
> 'fermeture du fichier (pas la peine de gaspiller la mémoire)
> Close #Fnum
>
> Et voici des extraits de la fonction de recherche (je simplifie car
> il a fallut gérer les gros fichiers (découpage en plusieurs parties
> de la zone à analyser) et la fonction InStr plantait) :
>
> RechStart = InStr(RechStart + 1, FichierLu, MotACherche,
> vbTextCompare)
>
> ' Le mot a été trouvé
> If RechStart <> 0 Then
> ...
> End If
>
> Voilou
>
> François




1 2