Grabbing 1st file in a directory 
Author Message
 Grabbing 1st file in a directory

I am trying to "peak" (too bad that command is gone in VB.NET) into a
directory with 20000+ files and "grab" the first file, move it to a
new location, and continue the program operation. I am using VB.NET
2008 and have the following code snippet

Public inputFiles(1) As String
Public firstFile As String

inputFiles = Directory.GetFiles(inputDir)
firstFile = inputFiles(0)

--This works but takes a few seconds (time is very important) which is
unacceptable. I thought the following would work

        Dim di As New IO.DirectoryInfo(inputDir)
        Dim firstFullPath = di(1).FullPath

but this doesn't work either I receive a System.IO.DirectoryInfo
cannot be indexed because it has no default property. I vaguely
remember using the "peak" command back in "C" to look into a directory
and see the first file. Is there something like this in VB?

Once the first file is grabbed and processed the routine will be
called again and the "next" file will be grabbed which would be
another "peak" command.

Thanks!



Sat, 12 May 2012 09:29:06 GMT  
 Grabbing 1st file in a directory

Quote:
> I am using VB.NET

This group is for VB6 and earlier(VB Classic). VB.Net and all dotnet groups
have either "dotnet" or "vsnet" in the group name. Please use the following
group instead:




Sat, 12 May 2012 09:51:53 GMT  
 Grabbing 1st file in a directory

Quote:
>I am trying to "peak"

You're trying to reach your highest potential? Or are you perhaps trying to
"peek"? Regardless, you're in the wrong group.


Sat, 12 May 2012 22:35:10 GMT  
 Grabbing 1st file in a directory

Quote:
> >I am trying to "peak"

> You're trying to reach your highest potential? Or are you perhaps trying
to
> "peek"? Regardless, you're in the wrong group.

  He's already got his answer in the .Net group.
(Where it turns out it can't be done with "managed"
code and he's been advised to choose between
.Net 4 beta [which I guess assumes he only needs
to run the software on his own XP SP3 or later PC]
or Win32 API.  As the saying goes, you couldn't
make this stuff up! :)


Sat, 12 May 2012 22:54:44 GMT  
 Grabbing 1st file in a directory


Wed, 18 Jun 1902 08:00:00 GMT  
 Grabbing 1st file in a directory

Quote:
> I am trying to "peak" (too bad that command is gone in VB.NET) into a
> directory with 20000+ files

Peek never existed in vb6 either.
Even in QBasic, it was nothing to do with file system access.

It was used for direct memory/hardware access which is no longer
available on normal NT systems due to the security model and process
isolation.

--

i-Catcher Development Team

iCode Systems



Sat, 12 May 2012 23:05:36 GMT  
 Grabbing 1st file in a directory


Wed, 18 Jun 1902 08:00:00 GMT  
 Grabbing 1st file in a directory

Quote:
>> >I am trying to "peak"

>> You're trying to reach your highest potential? Or are you perhaps trying
> to
>> "peek"? Regardless, you're in the wrong group.

>   He's already got his answer in the .Net group.
> (Where it turns out it can't be done with "managed"
> code and he's been advised to choose between
> .Net 4 beta [which I guess assumes he only needs
> to run the software on his own XP SP3 or later PC]
> or Win32 API.  As the saying goes, you couldn't
> make this stuff up! :)

Contrary to what you might think, the framework doesn't do everything - and
there are times, even in .NET where you must use the api for certain
functionality...

The op doesn't have to wait for .NET 4, those new methods are trivial to write
as a library of extension methods in C# (they are a bit harder in VB.NET because
VB.NET's iterator support sucks), which could then be imported into a current
project.

--
Tom Shelton



Sun, 13 May 2012 01:19:16 GMT  
 Grabbing 1st file in a directory


Quote:
>>   He's already got his answer in the .Net group.
>> (Where it turns out it can't be done with "managed"
>> code and he's been advised to choose between
>> .Net 4 beta [which I guess assumes he only needs
>> to run the software on his own XP SP3 or later PC]
>> or Win32 API.  As the saying goes, you couldn't
>> make this stuff up! :)

> Contrary to what you might think, the framework doesn't do everything -
> and
> there are times, even in .NET where you must use the api for certain
> functionality...

> The op doesn't have to wait for .NET 4, those new methods are trivial to
> write
> as a library of extension methods in C# (they are a bit harder in VB.NET
> because
> VB.NET's iterator support sucks), which could then be imported into a
> current
> project.

Heh, I was going to respond to this myself and point out that you can't do
it in "pure VB code" either but would have to resort to API calls like
FindFirstFile() or whatever it's called. Everything non-trivial we do
ultimately boils down to Windows API calls.


Sun, 13 May 2012 03:17:21 GMT  
 Grabbing 1st file in a directory
Jeff Johnson has brought this to us :

Quote:
> Heh, I was going to respond to this myself and point out that you can't do it
> in "pure VB code" either but would have to resort to API calls like
> FindFirstFile() or whatever it's called.

Huh?  Did I misunderstand the question, or would it not just be a
quick:

   Debug.Print Dir$(Path & "*.*")

That's all FFF is doing, afterall.  (Or, vice-versa. <g>)

--
[.NET: It's About Trust!]



Sun, 13 May 2012 07:01:36 GMT  
 Grabbing 1st file in a directory


Quote:
>> Heh, I was going to respond to this myself and point out that you can't
>> do it in "pure VB code" either but would have to resort to API calls like
>> FindFirstFile() or whatever it's called.

> Huh?  Did I misunderstand the question, or would it not just be a quick:

>   Debug.Print Dir$(Path & "*.*")

> That's all FFF is doing, afterall.  (Or, vice-versa. <g>)

Okay, now that I think about it, I guess that's right. Shows how long it's
been since I've used Dir().... Regardless of the bad example, the jist of
what Tom and I are saying holds true: If you must hate .NET, hate it for the
right reasons, not for whiny stuff.


Sun, 13 May 2012 23:26:26 GMT  
 Grabbing 1st file in a directory

Quote:
> Okay, now that I think about it, I guess that's right. Shows how long it's
> been since I've used Dir().... Regardless of the bad example, the jist of
> what Tom and I are saying holds true: If you must hate .NET, hate it for
the
> right reasons, not for whiny stuff.

  Whiny stuff? Eight years on with their masterpiece,
200+ MB of support files, and anyone who wants to
enumerate files needs to "wait for the next version"?

  That's comedy, not whiny. And Tom added to the
comedy without knowing it by explaining that one
need only write a C# library to handle the job. Like
I said, you couldn't make this stuff up. :)

  Actually, though, that all does seem to connect to
one of the "right reasons" to criticize .Net. It's
not so strong on basic shell/desktop functionality
because it was never intended to be. Which is fine
...if only MS didn't insist on telling people otherwise.



Mon, 14 May 2012 01:18:03 GMT  
 Grabbing 1st file in a directory


Quote:
>  Whiny stuff? Eight years on with their masterpiece,
> 200+ MB of support files, and anyone who wants to
> enumerate files needs to "wait for the next version"?

And there's the misrepresentation that I'm talking about. Taking that
sentence by itself, it seems you're saying that .NET can't enumerate files,
whereas the issue is that it doesn't have a NATIVE method to enumerate a
folder ONE FILE AT A TIME. Big freakin' deal. It can't handle a fringe case.
OH MY! WHAT A FAILURE IT MUST BE!

A) It's bad design on the part of the process creators that there are that
many files in the folder to begin with.

B) It's bad design on Microsoft's part that Windows has a performance issue
with reading folder structures once they get beyond a certain size. But this
is a file system issue and not the fault of .NET.

C) We tell people to use API calls from VB all the time, yet when someone
says you have to do it from .NET people lose their minds.

D) 200MB+ support files. So what? Really, so what? You got some hand-me down
hard drive from the early 90's or something?

I'm not saying .NET is perfect. Nothing is. But let's consider the Framework
versions:

1.0
1.1
2.0
3.0
3.5
4.0

4.0 is the sixth version of the Framework. What version did VB stop on?
What, SIX? Geez, it must really suck bad if they had to improve it SIX
times!! Oh, wait....

All I can say is that the only legitimate concerns I've ever heard voiced
over .NET were

A) Desktop application performance (Yes, it IS slower than a comparable VB
app.)

B) The way existing programmers (ESPECIALLY us VB people) got screwed with
the changeover.

Honestly, A is still valid, but I think people need to grow up and get over
B. I'm through being pissed that ".NET killed VB." VB.NET sucks--I'm still
100% on the same page with most folks around here about that--but I'm
talking about the language and not the .NET Framework itself. I find it to
be a big improvement over Classic VB. That's not to say that there COULDN'T
have been a COM-based VB7 or more that wouldn't be as good. There absolutely
could have been. But there wasn't. And now we have a 10-year-old+ product
that was still in need of improvements and stopped getting them. And in the
meantime those improvements got incorporated elsewhere. Can anyone really
argue over that point?



Mon, 14 May 2012 02:35:14 GMT  
 Grabbing 1st file in a directory

Quote:
> I'm through being pissed that ".NET killed VB." VB.NET sucks--I'm still
> 100% on the same page with most folks around here about that--but I'm
> talking about the language and not the .NET Framework itself. I find it to
> be a big improvement over Classic VB.

I want to clarify the statement above. I find the ".NET Framework wrapper
over Windows" to be a big improvement over "Classic VB's wrapper over
Windows." That is what I meant by "it." I did NOT mean I find VB.NET to be
an improvement over Classic VB.


Mon, 14 May 2012 03:09:39 GMT  
 Grabbing 1st file in a directory

Quote:

>> Okay, now that I think about it, I guess that's right. Shows how long it's
>> been since I've used Dir().... Regardless of the bad example, the jist of
>> what Tom and I are saying holds true: If you must hate .NET, hate it for
> the
>> right reasons, not for whiny stuff.

>   Whiny stuff? Eight years on with their masterpiece,
> 200+ MB of support files, and anyone who wants to
> enumerate files needs to "wait for the next version"?

You can enumerate files now.  

For Each file As FileInfo in Directory.GetFiles(myDirPath)
        ' do stuff
Next

or if you must:

Dim p As String = Dir("C:\")
While p <> ""
        Console.WriteLine(p)
   p = Dir()
End While

The question came up, because the current implementation does a complete
enumeration before returning.  This is not usually a problem, unless your
dealing with a lot of files - but can be wasteful if all you care about is the
first file or don't plan to process all of the files.

They are adding some methods in V4 that return an IEnumerable<T> interface so
that you can enumerate in a streaming manner - a pattern that is becomming
much more common in the framework.  Though it's trivial to write a
replacement right now (even in VB.NET - though, it's even easier in C#).

Quote:
>   That's comedy, not whiny. And Tom added to the
> comedy without knowing it by explaining that one
> need only write a C# library to handle the job. Like
> I said, you couldn't make this stuff up. :)

I suggested C# simply because it makes it slightly simpler to write the
enumerator.  It could be done in VB.NET, it just takes a bit more code.

public static IEnumerable<DirectoryInfo> EnumerateDirectories ( this DirectoryInfo target )
{
        string searchPath = Path.Combine ( target.FullName, "*" );
   NativeWin32.WIN32_FIND_DATA findData;
   using (NativeWin32.SafeSearchHandle hFindFile = NativeWin32.FindFirstFile ( searchPath, out findData ))
   {
        do
      {
        if ( (findData.dwFileAttributes & FileAttributes.Directory) != 0 && findData.cFileName != "." && findData.cFileName != ".." )
         {
                yield return new DirectoryInfo ( Path.Combine ( target.FullName, findData.cFileName ) );
         }
      } while ( NativeWin32.FindNextFile ( hFindFile, out findData ) );
    }

Quote:
}

I've obviously left out the api call declarations, but usage of the above
would look like:

DirectoryInfo root = new DirectoryInfo ( "C:\\" );
Console.WriteLine ( root.FullName );
foreach ( DirectoryInfo subDir in root.EnumerateDirectories () )
{
        Console.WriteLine ( "\t{0}", subDir.Name );

Quote:
}
>   Actually, though, that all does seem to connect to
> one of the "right reasons" to criticize .Net. It's
> not so strong on basic shell/desktop functionality
> because it was never intended to be. Which is fine
> ...if only MS didn't insist on telling people otherwise.

Which is again, rooted in your complete misunderstanding of .NET.

--
Tom Shelton



Mon, 14 May 2012 03:19:42 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Why is 1st line of text file overwritten?

2. Returning all file names from given folder directory and all sub-directories

3. Naming files in a directory after the directory

4. How to delete files but keep the directory and sub directories

5. How to grab excel.exe location by using a batch file

6. Grabbing Text From A Text File

7. grabbing info from a file

8. Grabbing records from 3 meg ascii file

9. Grabbing BMP file contents

10. *Correct syntax for grabbing binary file headers with .execute method(Internet Transfer Control)

11. HELP,HELP needed- grabbing text from text file

12. Grabbing incomplete files?

 

 
Powered by phpBB® Forum Software