I made 2 great functions called FoldersToProc and FilesToProc. They work like a system hook, and they call that proc with 2 parameters (Path and Finished). You can call them like this:
FilesToProc:
VB Code:
FilesToProc frmMain, "FileProc", VbMethod, "C:\"
Where frmMain is the object that holds the function, "FileProc" is the name of your function, VbMethod is the call type, and "C:\" is the base path of where to get the path of every file in and in all subdirectories.
Requirements for FileProc or whatever name you want:
VB Code:
Public Function FileProc(ByVal Path As String, ByVal Finished As Boolean) As Boolean
If Not Finished Then
'Do what you want with Path here
FileProc = True 'Continue receiving file paths
Else
'All file paths have been received, and
'Path does not include a file path.
End If
End Function
(Continued in next post)...
Last edited by xjake88x; Aug 25th, 2004 at 03:36 PM.
Where frmMain is the object that holds the function, "FolderProc" is the name of your function, VbMethod is the call type, and "C:\" is the base path of where to get the path of every subdirectory and their subdirectories etc.
Requirements for FolderProc or whatever name you want:
VB Code:
Public Function FolderProc(ByVal Path As String, ByVal Finished As Boolean) As Boolean
Private Sub FoldersToProc2(ByVal ProcObject As Object, ByVal ProcName As String, ByVal ProcCallType As VbCallType, ByVal lpPath As String, Optional TopLevel As Boolean = False)
If ProcAbort Then Exit Sub
Dim PathObject As Object, SubFoldersObject As Object, SubFolder As Object
Set FS = CreateObject("Scripting.FileSystemObject")
Set PathObject = FS.GetFolder(lpPath)
Set SubFoldersObject = PathObject.SubFolders
For Each SubFolder In SubFoldersObject
If CallByName(ProcObject, ProcName, ProcCallType, SubFolder, False) = Fals Then Exit Sub
Private Sub FilesToProc2(ByVal ProcObject As Object, ByVal ProcName As String, ByVal ProcCallType As VbCallType, ByVal lpPath As String, Optional TopLevel As Boolean = False)
Dim PathObject As Object, SubFoldersObject As Object, SubFolder As Object, SubFile As Object, SubFilesObject As Object
Set FS = CreateObject("Scripting.FileSystemObject")
FileSystemObject and CallByName aren't optimal to be honest. Defining an interface that you call back to would be better than CallByName, and the FSO isn't as good as the Win32 API calls proper.
Not APIs instead of CallByName, APIs instead of FileSystemObject.
I mean, in a class module define an interface then that has a FileProc and a FolderProc function, then implement that interface in the caller.
Then add the code to the function to call the appropriate functions on the object that implements the interface you pass in.
True, but the API does get a little messy. But it's worth it if you want it to run **** fast
Don't like the CallByName though, however, I feel that this may be the smaller contributer to the speed.
Why not use that code in a class, that have the class raise events?
Well how else besides callbyname can I make it so they specify a function that is called. There has to be a way, how else would they have made the callbyname function?
Here's the same thing, but tidied up into a neat class module.
Add a class slows the search down a little, but it's hardly noticable in my bench testing. 20ms or so.
That's what I posted above...Although you have a <>, why?
lngPos will never be less than 0, and if it is then you want to return the passed in string so no need to check for < 0.
Also, $, yea I forgot
Good addition.
Ok, you shouldn't rely on the skills of article writers: found out this to be untrue, when you turn on all of the advanced optimizations. If you don't turn the optimizations on, then there is some small disadvantage in using > than <>. But... who compiles his programs without the optimizations anyways?
Not gives interesting results. This was the code I used:
VB Code:
If Not (Something = 0) Then
End If
When Something was 1, it was generally the fastest. But when Something was 0, it was the slowest. Really really wondering the reason for this.
Anyways, we're talking about really small differences in speed here. If you turn all optimizations on, then it doesn't matter what you use, it is all just about equally fast and you get more varying in speed because of Windows' processes
Reply With Quote
2009 - 2016
