Re: Recurse folders - Great Code
- From: dsarvas@xxxxxxxxx (Don)
- Date: Wed, 07 Feb 2007 17:09:23 GMT
On Sun, 04 Feb 2007 04:46:28 +0100, Ulrich Korndoerfer
<ulrich_wants_nospam@xxxxxxxxxxxx> wrote:
Hi Don,
Don schrieb:
...
Just tried it. Even more impressed now. Your class works great. I
only encountered one problem and that was when I tried searching my
entire drive. Nothing showed up in the results text box (and no error
message) so I used a Rich Textbox instead, thinking maybe there was
too much text, and that did the trick. On the other hand, maybe I
was impatient and didn't wait long enough for results, but your code
does run fast - and with so little code for the user to have to mess
with. I like it.
Collecting all files on a drive may take some time. This is due to the
amount of files and to the OS calls which have to scan the whole drive.
My class does this as fast as eg. Windows Explorer in a search would do.
If you have waited long enough (the command button's caption reverts to
"Start search" from "Searching..."), there should be output in the text
box, even if no files were found (then "No files found" is output).
The command button did change back but I didn't get "No files found"
BUT THAT WAS MY FAULT. I didn't set the text box to multiline and
scroll bars. I just did that and your class file works great with the
text box back in place.
And remember, even if no files are found because your file name filter
excludes them all (say using "abcd.gfh" as filter which would only find
files of that name), the search is not much faster than a search
returning *all* files. That is because we always have to scan all
directories (that is read the dirs content) to be sure we do not
overlook a file.
Yes, I'm aware of that. Actually, I want to break out of a loop
searching all directories once I find the file I'm looking for. When
searching an entire hard drive, the time can be a little longer than I
would like, particularly if the file sought has been found. On the
other hand, my use for this procedure is one where I may want to do
multiple searches. In that case, since, as you say, the results are
all stored internally, searching for additional files should be close
to instantaneous. That may be more important than the fact an initial
search may take some time on a huge hard drive.
With the Rich Textbox I can also do more with the resulting text
output.
That's fine. The class stores the search's result internally and it is
up to you which parts of the search (eg file names only, dirs only, file
attributes etc) you will print out in the GUI and which control you will
use for this. Indeed the rich text box is more accomodated for big
amounts of text, but also adds overhead to the text data.
After a search, as long you hold a reference to the class instance that
did the search, all the data is available and you can query the data eg.
many times under different aspects.
I noticed when run a second time, it's VERY fast. I'm assuming the
result of caching, but now I'm more interested in expanding what this
can do for me.
Yes, this caching is done by Windows for you. You will see the same
effect when doing a search using windows Explorer. A second run always
is significantly faster. However when using my class it is not necessary
to do a second run, as all the data gathered from the first run is still
there.
If you are eg searching for many different files (having different names
or extensions), your best bet is to do a search including *all* files
(using "*" as file name filter) and then just extract the files you are
interested in. The class holds the data for all files in memory (even if
there are tens of thousands or hundreds of thousands) and you can search
them now from memory, which is much faster (even when taking into
account that the system does caching) as to start a new search for each
files of interest.
And that's REALLY handy. I've altered other code I found to write to
a text file so I could reuse again without another recursing of
folders to reestablish the tree structure and list of files.
I can see a lot can be done with this. When I get a chance I'll have
to review the source code as you mentioned. I'm no pro at programming
but I should get a pretty good education from this. I'm pretty new at
working with API functions. This is the first time I added a class
file to an application.
Now you could see how easy classes make working with difficult
functionality. The class encapsulates all that stuff (hides its inner
workings) and gives you some handy, simple methods to get your work
done. You should use classes more often :-)
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
-----------------------------------------------------------------------
Plea for a bright future for VB classic.
Sign the petition to Microsoft: -> http://classicvb.org/petition/
-----------------------------------------------------------------------
.
- Follow-Ups:
- Re: Recurse folders - Great Code
- From: Ulrich Korndoerfer
- Re: Recurse folders - Great Code
- References:
- Re: Recurse folders - Great Code
- From: Don
- Re: Recurse folders - Great Code
- From: Ulrich Korndoerfer
- Re: Recurse folders - Great Code
- From: Don
- Re: Recurse folders - Great Code
- From: Ulrich Korndoerfer
- Re: Recurse folders - Great Code
- Prev by Date: Re: Long live Classic!
- Next by Date: Re: 10 to 20 item optimizer?
- Previous by thread: Re: Recurse folders - Great Code
- Next by thread: Re: Recurse folders - Great Code
- Index(es):
Relevant Pages
|
