From: Helmut Meukel on

"MikeD" <nobody(a)nowhere.edu> schrieb im Newsbeitrag
news:OkwT9UbsKHA.3536(a)TK2MSFTNGP06.phx.gbl...
>
>
> "catharinus" <csvanderwerf(a)planet.nl> wrote in message
> news:5aa9d224-bae2-4bef-99ee-bc7761cc0d2f(a)g26g2000yqn.googlegroups.com...
>> Hello
>>
>> I am trying to quickly show the txt-files which are located in for
>> example 320 subfolders of a folder and read the content of those files
>> in a listview of a form. I can't find a QUICK way to do this. Should I
>> use Sendmessage to do this? And if Yes ,how should I do this?
>
>
> So you're searching for txt files in 320 folders? And then reading those
> files and loading their contents into a listview? And what would your idea be
> (time-wise) of doing this quickly? There are many factors involved. Do any of
> those 320 subfolders have their own subfolders that you're also searching?
> Approximately how many txt files? Are you loading the entire contents of ALL
> txt files into the ListView (and why a ListView)? That could take anywhere
> from a couple of minutes to perhaps several hours. It all depends, not only on
> just the couple things I mentioned but also the computer and its hardware.
>
> Probably your best option to find the files is to use the FindFirstFile,
> FindNextFile, and FindClose API functions. Search the newsgroup for
> FindFirstFile and you'll find plenty of example code to use these functions in
> a recursive procedure (recursion is what makes it possible to specify one
> folder and search all its subfolders).
>
> For reading each file's contents, I'd think VB's own file I/O should be fine.
>
> You're also probably going to find that this will slow down exponentially as
> you add more and more ListItems into the ListView. Which is why I question
> using a ListView for this.
>
> --
> Mike
>

To add to this: even one folder with many text files - even small ones -
will slow down the OS in accessing its directory. One of my customers
knits medical stockings - made to measure - and got the orders as plain
text files transfered via RAS into a shared directory. Our programs
processed the data and moved the files to an archive directory.
Small files of 400 to 800 bytes, but 300 to more than 400 per day.
We found that storing more than 20,000 files (3 months) in one directory
was a bad idea, the system slowed down to a crawl when accessing
these directories.

Helmut.

From: MikeD on


"Helmut Meukel" <NoSpam(a)NoProvider.de> wrote in message
news:uTIBSsbsKHA.6004(a)TK2MSFTNGP04.phx.gbl...

> To add to this: even one folder with many text files - even small ones -
> will slow down the OS in accessing its directory. One of my customers
> knits medical stockings - made to measure - and got the orders as plain
> text files transfered via RAS into a shared directory. Our programs
> processed the data and moved the files to an archive directory.
> Small files of 400 to 800 bytes, but 300 to more than 400 per day.
> We found that storing more than 20,000 files (3 months) in one directory
> was a bad idea, the system slowed down to a crawl when accessing
> these directories.
>

Good comment and definitely something to be aware of, but in this case we
can rule that out per a later post with a little more information.

--
Mike



From: Karl E. Peterson on
MikeD wrote:
> So your complaint is that it takes 7 seconds to search 320 subfolders for
> .txt files and display the contents of those files in a ListView? What make
> you think it should only take 1 second? IMO, 7 seconds is not that bad. As I
> said, I could see it taking minutes to hours, depending on number of files,
> size of those files, etc., etc. Maybe these bookkeepers just need faster
> computers, or faster hard drives, or maybe they just need to defrag their
> hard drives.

Or maybe they just need an IT dept, or even a dept guru, with a clue.
320 folders, *each* with a single TXT file??? That's pretty funny.

--
..NET: It's About Trust!
http://vfred.mvps.org


From: catharinus on
On 20 feb, 00:42, Karl E. Peterson <k...(a)exmvps.org> wrote:
> MikeD wrote:
> > So your complaint is that it takes 7 seconds to search 320 subfolders for
> > .txt files and display the contents of those files in a ListView?  What make
> > you think it should only take 1 second? IMO, 7 seconds is not that bad. As I
> > said, I could see it taking minutes to hours, depending on number of files,
> > size of those files, etc., etc. Maybe these bookkeepers just need faster
> > computers, or faster hard drives, or maybe they just need to defrag their
> > hard drives.
>
> Or maybe they just need an IT dept, or even a dept guru, with a clue.  
> 320 folders, *each* with a single TXT file???  That's pretty funny.
>
> --
> .NET: It's About Trust!http://vfred.mvps.org

Thanks my friends
As have read this with a smile on my face as you probarbly can
understand. I will reconsider the options, for example the firstfile
nextfile option Thanks
Cath
From: Karl E. Peterson on
catharinus wrote:
> On 20 feb, 00:42, Karl E. Peterson <k...(a)exmvps.org> wrote:
>> MikeD wrote:
>>> So your complaint is that it takes 7 seconds to search 320 subfolders for
>>> .txt files and display the contents of those files in a ListView? �What
>>> make you think it should only take 1 second? IMO, 7 seconds is not that
>>> bad. As I said, I could see it taking minutes to hours, depending on number
>>> of files, size of those files, etc., etc. Maybe these bookkeepers just need
>>> faster computers, or faster hard drives, or maybe they just need to defrag
>>> their hard drives.
>>
>> Or maybe they just need an IT dept, or even a dept guru, with a clue. �
>> 320 folders, *each* with a single TXT file??? �That's pretty funny.
>
> Thanks my friends
> As have read this with a smile on my face as you probarbly can
> understand. I will reconsider the options, for example the firstfile
> nextfile option Thanks

Happy to see it was taken in the same spirit offered. :-)

--
..NET: It's About Trust!
http://vfred.mvps.org