FinfFirst, FindNext per cercare più estensioni
MBulu
supponiamo di dover fare una ricerca con FindFirst e FindNext di tutti i
files che hanno almeno una delle seguenti estensioni:
*.aaa
*.bbb
*.ccc
e che tale ricerca vada fatta su tutte le directories del disco. E'
possibile dire a FindFirst di cercare tutti i files che soddisfano almeno
una delle estensioni?
Ad oggi faccio una ricerca con *.* e poi verifico io che l'estensione ricada
tra una di quelle.
Grazie in anticipo, Mario
--------------------------------
Inviato via http://arianna.libero.it/usenet/
Jax
> Ad oggi faccio una ricerca con *.* e poi verifico io che l'estensione ricada
> tra una di quelle.
Anch'io me lo sono sempre chiesto, ma non ho mai approfondito.
Guardando i sorgenti, FindFirst si basa si una API (FindFirstFile), ed è
questa API che non prevede il passaggio di più estensioni.
Neanche la FindFirstFileEx lo prevede, quindi l'unica soluzione
alternativa, così sui due piedi, potrebbe essere farsi una procedura
generica a cui viene passata l'estensione, che verrà richiamata per ogni
estensione ricercata.
Bisognerebbe fare delle prove per vedere se e in quali condizioni questa
soluzione sia più veloce della ricerca *.*
--
Jax
MBulu
> Neanche la FindFirstFileEx lo prevede, quindi l'unica soluzione
> alternativa, così sui due piedi, potrebbe essere farsi una procedura
> generica a cui viene passata l'estensione, che verrà richiamata per ogni
> estensione ricercata.
> Bisognerebbe fare delle prove per vedere se e in quali condizioni questa
> soluzione sia più veloce della ricerca *.*
Ci avevo pensato anch'io, ma ho notato che se la ricerca viene fatta
partendo per esempio da C:\, alla fine conviene cercare *.* e poi fare un
filtro sulla lista dei risultati. Nel primo caso infatti in disco viene
letto una volta sola, nell'altro caso verrebbe riletto più volte in baso al
n° di estensioni da trovare e le operazioni fatte in memoria sono più veloci
di quelle fatte su disco.
Almeno questo nel mio programma in cui posso arrivare a cercare fino a 10
estensioni differenti.
Ciao e grazie ancora, Mario.
ACSH
> Ci avevo pensato anch'io, ma ho notato che se la ricerca viene fatta
> partendo per esempio da C:, alla fine conviene cercare *.* e poi fare un
> filtro sulla lista dei risultati. Nel primo caso infatti in disco viene
> letto una volta sola, nell'altro caso verrebbe riletto più volte in baso al
> n° di estensioni da trovare e le operazioni fatte in memoria sono più veloci
> di quelle fatte su disco.
> Almeno questo nel mio programma in cui posso arrivare a cercare fino a 10
> estensioni differenti.
Se stai usando Lazarus, quindi programmando in un ottica multipiattaforma,
non devi dare per scontato questo fatto.
Ma, visto che parli di "estensione", direi che ti limiti a Windows, e
quindi tutto quello che avete detto è valido e corretto. In tal caso,
potresti dere un occhio alla funzione AdvBuildFileList nelle libreria
Jedi, che dovrebbe fare proprio quello di qui hai bisogno.
Ciao
ACSH
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
MBulu
> Se stai usando Lazarus, quindi programmando in un ottica multipiattaforma,
> non devi dare per scontato questo fatto.
> Ma, visto che parli di "estensione", direi che ti limiti a Windows, e
> quindi tutto quello che avete detto è valido e corretto. In tal caso,
> potresti dere un occhio alla funzione AdvBuildFileList nelle libreria
> Jedi, che dovrebbe fare proprio quello di qui hai bisogno.
In effetti lo faccio con Lazarus ed il programma è compilato anche in Linux.
Nel mio caso vado alla ricerca di files PDF e di OpenOffice (ODS, ODT, ecc)
in ogni caso ho previsto che l'utente possa inserire un filtro e, se vuole,
la ricerca viene fatta anche senza estensioni !!!
Mi attacco a questo thread per chiedere un consiglio: dovendo cercare i
files potenzialmente su tutto il disco, faccio una ricerca con i classici
FindFirst, FindNext e FindClose in una procedura ricorsiva. Durante
l'esecuzione, sorge il problema dell'applicativo che sembra in loop. Per
risolvere ho messo un Application.ProcessMessages all'inizio della procedura
ricorsiva. La cosa però non mi piace molto perché
l'Application.ProcessMessages verrebbe richiamato ad ogni cambio di
directory e, su un disco con molte directories, andrebbe a "rubare" del
tempo all'esecuzione.
Mi è venuta in mente adesso mentre scrivevo, di mettere
Application.ProcessMessages nell' OnShow del form ma non ci ho ancora
provato.
Voi in casi del genere come vi comportate?
Ciao e grazie ancora, Mario
Microges
MBulu
> Scusa ma usare un Thread?
>
Non li ho mai usati !!!
In quel caso cosa cambia? L'applicativo non sembra ugualmente bloccato?
Ciao, Mario
Microges
> Non li ho mai usati !!!
Be questo non e' un problema, in giro vi sono una miriade di esempi dai
piu' semplici ai piu' complessi
> In quel caso cosa cambia? L'applicativo non sembra ugualmente bloccato?
No. Un thread e' un processo parallelo al tuo. Un po' come se avvii due
programmi simultaneamente - se uno e' bloccato, l'altro non lo e' -
Giorgio Padoan
news:62Z108Z225Z151Y...@usenet.libero.it...
Il Thread sarebbe l'ideale, cmq puoi far in modo che
l'application.processedMessage venga richiamato ogni tot. esecuzioni del
ricorsivo,
oppure usando le funzione sul "Time" ogni tot. millisecondi, Giorgio
Andrea Laforgia
>Mi attacco a questo thread per chiedere un consiglio: dovendo cercare i
>files potenzialmente su tutto il disco, faccio una ricerca con i classici
>FindFirst, FindNext e FindClose in una procedura ricorsiva. Durante
>l'esecuzione, sorge il problema dell'applicativo che sembra in loop.
Crea un thread a cui fai eseguire tutta l'operazione di ricerca.
Thread che dovr� comunicare con la main form o chi di dovere mediante
messaggi (o tecnica equivalente) i risultati che trova di volta in
volta. Non � complicato farlo.
Andrea Laforgia
>In quel caso cosa cambia? L'applicativo non sembra ugualmente bloccato?
No, i thread sono percorsi di esecuzione paralleli.