FindFirstFileEx() and Unicode
-
Edit: I deleted the upload, forgot I was in the middle of trying an ASCII version. Will repost a link once I get it back to Unicode. That's strange. I tried running it on a low privilege account and it run fine on Vista/32 bit. In case anything got messed up while I was trying to post the code(I had some issues) I've uploaded the project (VS2008) to: http://sdrv.ms/18SnASR This version is a bit different because I've been playing with it bit this evening. You will also find the syntax for the FindFirstFileEx function in the scraps.txt file. Try un-commenting the code in this block:
If hFile.DangerousGetHandle.ToInt32 = -1 Then
' just ignoring errors for this demo, most common is 5 - Access Denied
' System Error Codes
' http://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx
Dim [error] As Int32 = Marshal.GetLastWin32Error()
Stop
Return
Elseand see what error code, if any, you are getting.
-
Here is the updated project link that I mentioned in my previous post. http://sdrv.ms/13fhQi8[^]
-
So the problem WAS in my version of the WIN32_FIND_DATA structure. I copied your declarations over to replace mine and other than having to provide something other than null for the initial values, nothing else was required. After doing that, my program works fine. But I do not understand why my declarations were wrong. ------------------------------------------------------------------------------------------------- Edit: vb had a banner over my function declaration that was telling me that I might have to martial the WIN32_FIND_DATA structure. I thought it was only referring to the two strings. But why was martialing required everywhere else? ------------------------------------------------------------------------------------------------- The last two for the strings were what vb.Net suggested when I originally converted my vb6 program over to net, which apparently, in this case, were not the correct solutions. For the other declarations, FILETIME did not work, and the one that bothers me the worst is that Uint32 did not work. Isn't U4 (Unsigned 4 bytes) the same in principal as Uint32 (Unsigned 4 bytes)? My old structure:
Private Structure WIN32_FIND_DATA
Dim dwFileAttributes As UInt32
Dim ftCreationTime As FILETIME
Dim ftLastAccessTime As FILETIME
Dim ftLastWriteTime As FILETIME
Dim nFileSizeHigh As UInt32
Dim nFileSizeLow As UInt32
Dim dwReserved0 As UInt32
Dim dwReserved1 As UInt32Public cFileName As String Public cAlternate As StringEnd Structure
Your structure:
_
Private Class WIN32_FIND_DATA
Public dwFileAttributes As IO.FileAttributes = 8208
Private ftCreationTime_dwLowDateTime As UInt32 = 0
Private ftCreationTime_dwHighDateTime As UInt32 = 0
Private ftLastAccessTime_dwLowDateTime As UInt32 = 0
Private ftLastAccessTime_dwHighDateTime As UInt32 = 0
Private ftLastWriteTime_dwLowDateTime As UInt32 = 0
Private ftLastWriteTime_dwHighDateTime As UInt32 = 0
Publi -
Here is the updated project link that I mentioned in my previous post. http://sdrv.ms/13fhQi8[^]
-
TnTinMn, I am curios about your usage of U4. Isn't U4 (Unsigned 4 bytes) the same in principal as Uint32 (Unsigned 4 bytes)?
Like most people, I have some bad habits. :) I will decorate the fields with MarshalAs even if it is not needed. It is usually an indication that my first attempt failed (i.e. I copied the declaration for PInvoke.com and it was incorrect) and then I checked the un-managed declaration for the expected type or that I wrote the declaration myself based on the specification. You are correct concerning the U4 usage. It is not needed when using a UInt32 for a dword field. see: Blittable and Non-Blittable Types
-
Like most people, I have some bad habits. :) I will decorate the fields with MarshalAs even if it is not needed. It is usually an indication that my first attempt failed (i.e. I copied the declaration for PInvoke.com and it was incorrect) and then I checked the un-managed declaration for the expected type or that I wrote the declaration myself based on the specification. You are correct concerning the U4 usage. It is not needed when using a UInt32 for a dword field. see: Blittable and Non-Blittable Types
Got you. Thanks for the learning. I will say that data typing can be pretty difficult. All it takes is screwing up a ByRef for a ByVal and not figuring it out until an hour later. So I can thoroughly understand using marshaling just to be on the safe side. I wish they would simplify the syntax, however. Like, maybe, "U4ToUInt32(parameter name)". That way, a quick marshaling could be done without having to worry about a long verbose syntax, let alone trying to remember the path of the namespace.
-
Got you. Thanks for the learning. I will say that data typing can be pretty difficult. All it takes is screwing up a ByRef for a ByVal and not figuring it out until an hour later. So I can thoroughly understand using marshaling just to be on the safe side. I wish they would simplify the syntax, however. Like, maybe, "U4ToUInt32(parameter name)". That way, a quick marshaling could be done without having to worry about a long verbose syntax, let alone trying to remember the path of the namespace.
Quote:
... let alone trying to remember the path of the namespace.
Organize your code and move all interop to a separate file and set the proper Imports statements at the top of the code. Then to really mess with those who read your code but never the MSDN language specification :mad:, set an alias for the Imports. :wtf:
Imports sri = System.Runtime.InteropServices
Imports lok = System.Runtime.InteropServices.LayoutKind
Imports umt = System.Runtime.InteropServices.UnmanagedType<sri.StructLayout(lok.Sequential)> _
Public Class Class1
<sri.MarshalAs(umt.U4)> Public Fred As UInt32
End ClassJust be careful with the aliasing, there is glitch in their implementation that lets you alias all the way to the class/type name. That is just plain wrong as discussed here.[^]
-
Quote:
... let alone trying to remember the path of the namespace.
Organize your code and move all interop to a separate file and set the proper Imports statements at the top of the code. Then to really mess with those who read your code but never the MSDN language specification :mad:, set an alias for the Imports. :wtf:
Imports sri = System.Runtime.InteropServices
Imports lok = System.Runtime.InteropServices.LayoutKind
Imports umt = System.Runtime.InteropServices.UnmanagedType<sri.StructLayout(lok.Sequential)> _
Public Class Class1
<sri.MarshalAs(umt.U4)> Public Fred As UInt32
End ClassJust be careful with the aliasing, there is glitch in their implementation that lets you alias all the way to the class/type name. That is just plain wrong as discussed here.[^]
I certainly would not like to have to go looking for the an alias, except when lines start getting too long and too numerous. That means I have to jump all over the place to find it, and then I might lose my train of thought. That's true of my own code, too, especially after having not looked at it in ages. That one example reminds me of someone deliberately trying to make their code obscure so that people will have a hard time understanding it. Works fine, unless you forgot you did it and you come back later and say, "What the F!". I don't understand why the IDE doesn't see something crazy-wrong like
using string = int32. -
Howdie. I am researching how to use the Unicode version of FindFirstFileEx() in vb.Net and am having a heck of a time getting this to work. I had downloaded an example and it used the standard version, FindFirstFile(). I then modified the code to work with FindFirstFileEx(), instead, and got that to work, too, but only for ANSI characters (Alias "FindFirstFileExA"). But when I attempted to use the Unicode version (Alias "FindFirstFileExW"), it fails miserably. The best I have been able to do is get a non-zero return value from the function (which means it found the folder), but all the returned WFD structure contains are null strings for the folder name and alternate folder name. I have googled the problem (MSDN is of no help in this regard) and did find one reference on how to alter the function parameters to provide pointers instead of a string and the WFD structure, themselves. At any rate, here is my code for just the top half that looks for folders. The bottom half deals with searching for files, but it is just a repeat of this example, essentially. If I can get this top half to work with your help, I can certainly get the bottom half to work. I would have liked to attach a zip containing the project and the test folder I used, but it does not look like attachments are possible, here. Thanks for any help!
Option Strict Off
Option Explicit On
'Option Infer OffImports VB = Microsoft.VisualBasic
Imports System.Runtime.InteropServicesFriend Class Form1
Inherits System.Windows.Forms.Form'Private Declare Function FindFirstFileExW Lib "kernel32.dll" Alias "FindFirstFileExW" (ByVal lpFileName As String, ByVal fInfoLevelId As FINDEX_INFO_LEVELS, ByVal lpFindFileData As WIN32_FIND_DATA, ByVal fSearchOp As FINDEX_SEARCH_OPS, ByRef lpSearchFilter As Int32, ByVal dwAdditionalFlags As Integer) As Long
Private Declare Function FindFirstFileExW Lib "kernel32.dll" Alias "FindFirstFileExW" (ByVal lpFileName_IntPtr As IntPtr, ByVal fInfoLevelId As FINDEX_INFO_LEVELS, ByRef lpFindFileData_IntPtr As IntPtr, ByVal fSearchOp As FINDEX_SEARCH_OPS, ByRef lpSearchFilter As Int32, ByVal dwAdditionalFlags As Integer) As LongPrivate Declare Function FindNextFileW Lib "kernel32" Alias "FindNextFileW" (ByVal hFindFile As Long, ByRef lpFindFileData As WIN32_FIND_DATA) As Integer
Private Declare Function GetFileAttributesW Lib "kernel32" Alias "GetFileAttributesW" (ByVal lpFileName As String) As Integer
Private Declare Function FindClose Lib "kernel32" (ByVal hFindFile A
Hey, has anyone heard of the Delimon.win32.IO library? I just ran into it at MS and it it is a direct replacement for the System.IO functions, with same function names, to boot. The great part is that it crosses the MAX_PATH barrier by design. It requires NET Framework 4. So that means VS2010, unless there is a way to get VS2008 to see it. If someone mentioned this earlier, I apologize. But I did not find anything on it when doing a search here. I have added a reference to it in my project and am about to test it. UPDATE: Is NOT a direct replacement! Going through the properties/methods, a lot are simply not there, or stuff has been moved around and called by different names. Not sure if it completely covers all the functionality of System.IO. Also, since it requires framework 4, I don't think WinXP can use it. Which is a bummer since there are still a lot of XP systems out there. UPDATE 2: It MAY be a direct replacement after all...I might have attempted to type in methods while the dll reference was not properly set up. At any rate, this is a brand new library apparently, and it IS buggy. For instance, Directory.Exists and File.Exists methods do not filter correctly...Each returns "True" regardless of whether the resource is a folder or a file.