Using code to find the newest file in a folder.

[tedsmith]

I see there are are a variety of ways of finding the newest file with a particular extension in a folder.

Some are very verbose needing a number of steps and a Quicksort routine or ADO and those using APIs with pages of code.

Any suggestions as to what would be the neatest most direct way of doing this?

For instance I might have a few .CSV with different filenames and other types of files in the same directory.
I just want to be able to get the last CSV made and ignore the others.

 

[tedsmith]

I tried using FSO and it seems to be the simpest.

Dim FileDate As Variant
Dim NewestFile As String
Dim FSO As New FileSystemObject
Dim MyFile As File

FileDate = ""
For Each MyFile In FSO.GetFolder(ImportFolder).Files
   If FileDate = "" Then
       NewestFile = MyFile.Name
       If UCase(Right(NewestFile, 3)) = "CSV" Then FileDate = MyFile.DateLastModified 'first CSV file encountered
   Else
      If UCase(Right(MyFile.Name, 3)) = "CSV" And DateDiff("s", MyFile.DateLastModified, FileDate) < 0 Then
          NewestFile = MyFile.Name 'replace with any CSV file that is newer
          FileDate = MyFile.DateLastModified
      End If
   End If
Next
'Newestfile contains the wanted CSV file

Is there perhaps a way of nominating the extension in the FSO getfolder statement itself instead of using Right?

 

[fredericofonseca]

using VB6 is only direct way that I know of.

with .net there are easier ways, and if speed is highly important and you dealing with folders with 50k files or more then this is the fastest around

http://help.csharptest.net/?CSharpTest.Net.Library~CSharpTest.Net.IO_namespace.html

(once you fix one minor error on their code )

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[tedsmith]

Thanks but can this be incorporated in to a Vb6 program?

 

[fredericofonseca]

the link? its just another DLL so yes it can

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[strongm]

Here's how you might do it using 'classic' file handling functions:

[blue]Public Sub Example(strPath As String, Optional strPattern As String = "*")
    Dim filename As String
    Dim currentdate As Date
    Dim newestdate As Date
    Dim foundfile As String
    
    filename = strPath & Dir(strPath & strPattern)
    Do Until filename = strPath
        currentdate = FileDateTime(filename)
        If currentdate > newestdate Then
            newestdate = currentdate
            foundfile = filename
        End If
        filename = strPath & Dir()
    Loop
    Debug.Print foundfile, newestdate
End Sub[/blue]

 

[tedsmith]

Thanks, that was what I was looking for but couldn't quite get the syntax right.

"basic, better best" as they say in the BBC TV series Antique Roadshow

 

[strongm]

>can this be incorporated in to a Vb6 program?
>its just another DLL so yes it can

Um ... just because something is a DLL does not mean that it can be incorporated into VB6. The libraries referenced by the link are .net assemblies, and not useable in VB6

 

[fredericofonseca]

https://support.microsoft.com/en-us/kb/817248

would that work strongm?

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[strongm]

Afraid not.

I didn't say that no .net dlls could be used by VB6.

However, for a .net assembly DLL to be useable by VB6 a number of hoops have to be jumped through first, mainly that the assembly has to have been designed at the outset to allow interaction with COM, and must be specifically compiled with a specific flag (that is not normally set): Register for COM Interop (just setting that flag won't help if the assembly hasn't been designed for COM Interop use).

And once you get that DLL (and a matching TLB that is generated during the compilation) there is still some shenanigans necessary to register it correctly on a client PC - you can't simply copy it onto the client and expect it to work. Nor will regsvr32 work on it (that's one of the reasons that you need the TLB).

So, in summary. A .net generated DLL is not directly useable from VB6 without a TLB and proper registering - and such a TLB (and compatible DLL) will not be generated unless the assembly has been specifically designed and compiled to support COM Interop.

The CSharpTest libraries do not meet any of these requirements, and thus cannot 'be incorporated in to a Vb6 program'.

 

[fredericofonseca]

Thanks for explanation - eventually a bit of changes could allow them to work - not sure if original developer would be willing to do it but anyone searching for it may find this thread and do it themselves. (I don't need it but still good to know).

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[strongm]

Well, you could do, yes - but since a quick look at the source code shows that it is just a wrapper for the FindFirstFileEx and FindNextFile Win32 API calls you'd be better off calling those directly from VB6 (which we've certainly illustrated in this forum before)

 

[dilettante]

And that's all the Dir() function does anyway. The only advantage in making the API calls directly offers is the ability to make wide (Unicode) calls instead of the ANSI ones.

VB6 only does that because Windows 95 didn't support the wide calls (out of the box) and people were still using Windows 95 a lot yet in 1998.

 

[strongm]

>And that's all the Dir() function does anyway

Yep - although to be pedantic I thought it only wrapped FindFirstFile rather than FindFirstFileEx, but I'm happy to be corrected on this.

 

[dilettante]

Nope, I missed the -Ex suffix when I read that. I was laughing too hard at how much struggling went on here over such a newbie issue.

This site is getting as bad as StackOverflow. Is there an "unjoin" link somewhere?

 

[tedsmith]

<such a newbie issue.>
If you read my initial post I said I knew there were a variety of ways.
(I probably could have done it with a DOS batch file)
I was interested in seeing if there was a neater(more elegant?) way I hadn't considered and what people's opinion of what was the BEST way.
I would guess all the ways end up doing much the same basic thing when it it gets to the real guts level anyway.

Got to keep the forum alive somehow to help newbies become experts.

I'll let you know if I get something really meaty again.

You are never too old to learn (although it gets harder - I was 79 the other day) and you won't know what to learn unless you ask.

 

[dilettante]

This is billed as a site for professionals. That puts the onus on members to red-flag the hell out of posts, but it also gets so tedious nobody bothers. As a result script kiddies and hacks run rampant in here.

 

[tedsmith]

I agree with you.
Well in spite of the scorn and derision I often get for doing things the simple or old fashioned way I still consider myself a professional in that it has been virtually my only source of income since 1985 and has provided for a modest comfortable semi-retirement. (so I can't be doing too badly seeing I have visited 33 different countries so far.)
How many professionals freelancers can say the same thing?

It won't stop me from asking one of the more learned and advanced 'hacks' that inhabit this forum what they might think is an 'obvious question' and trying to help newbies to become professionals. It might help others with the same question.

I believe it is more important to supply software that works with zero bugs in it even if it uses something unfashionable or clumsily written. That's when you get repeat business.