I'm not quite sure what's going on, but, here goes: I have a project in VB.NET 2005 going. I make a call to an unmanaged function. I'm using the declaration below:
Private Declare Function GetWindowModuleFileName Lib "user32.dll" Alias "GetWindowModuleFileNameA" (ByVal hwnd As Integer, ByRef pszFileName As String, ByVal cchFileNameMax As Integer) As Integer
Now, elsewhere, I have a call that looks like this:
Dim Str As String Dim StrLen As Integer StrLen = 300 Str = Space(StrLen) StrLen = GetWindowModuleFileName(iHwnd, Str, StrLen)
...where iHwnd is passed in as a parameter. I do know that in each case iHwnd is a valid handle.
Here's the weird part: I get a PInvokeStackImbalance Exception complaining about a probable mismatch in the function's signature. The thing is, this code is only called when I hit a certain key. Now, if, say, Notepad or the DevEnv has the focus and I hit the key, all is well and my code works fine. However, when a couple of apps have the focus (e.g. Windows Explorer) and I hit the key, I get that PInvokeStackImbalance.
Can anyone help? If more info is needed, just let me know.
>Private Declare Function GetWindowModuleFileName Lib "user32.dll" >Alias "GetWindowModuleFileNameA" (ByVal hwnd As Integer, ByRef >pszFileName As String, ByVal cchFileNameMax As Integer) As Integer
pszFileName should be passed ByVal. The hwnd parameter should be of type IntPtr (but it only makes a real difference if you run on Win64).
> >Private Declare Function GetWindowModuleFileName Lib "user32.dll" >>Alias "GetWindowModuleFileNameA" (ByVal hwnd As Integer, ByRef >>pszFileName As String, ByVal cchFileNameMax As Integer) As Integer
> pszFileName should be passed ByVal. The hwnd parameter should be of > type IntPtr (but it only makes a real difference if you run on Win64).
btysgtma...@gmail.com wrote: > I'm not quite sure what's going on, but, here goes: I have a project > in VB.NET 2005 going. I make a call to an unmanaged function. I'm > using the declaration below:
For future questions about calling unmanaged functions, please use microsoft.public.dotnet.framework.interop, which specializes in these questions. You can also use microsoft.public.dotnet.languages.vb for VB.NET-specific questions. This group is for questions about the Common Language Framework in general.
> Private Declare Function GetWindowModuleFileName Lib "user32.dll" > Alias "GetWindowModuleFileNameA" (ByVal hwnd As Integer, ByRef > pszFileName As String, ByVal cchFileNameMax As Integer) As Integer
Personally I prefer to use DllImportAttribute for all .NET languages, as it allows you to be more precise than the native VB.NET syntax and works the same across languages. The only drawback is the uninuitive empty function body which you'll need to supply.
The correct declaration for this function would be:
<DllImport("user32.dll", EntryPoint := "GetWindowModuleFileNameA", CharSet := CharSet.Ansi, ExactSpelling := True)> _ Private Shared Function GetWindowModuleFileName(ByVal hwnd As IntPtr, ByVal pszFileName As StringBuilder, ByVal cchFileNameMax As Integer) As Integer ' Leave empty. End Function
You'll notice that we're passing a StringBuilder for the output string. This is necessary because ByRef on P/Invoke parameters doesn't work like you expect: rather than passing a "mutable" version of your object, it will pass a pointer to the object. So if you pass a string, it will pass a pointer to the string, which is wrong, because a string will already be marshaled as a pointer to characters. The confusing result is that the unmanaged side ends up with a pointer to a pointer, which is not what the function is expecting.
Luckily, the marshaller knows how to deal with this if we pass a StringBuilder instead.
> Now, elsewhere, I have a call that looks like this:
The correct call is now something like this:
Dim FileNameBuilder As New StringBuilder(300) Dim FileName As String GetWindowModuleFileName(iHwnd, FileNameBuilder, FileNameBuilder.Capacity) FileName = FileNameBuilder.ToString()
Please make sure to also read http://support.microsoft.com/?id=228469, because the usefulness of this function is severely limited on platforms other than Windows 95/98/ME.
On Jan 10, 2:37 pm, Jeroen Mostert <jmost...@xs4all.nl> wrote:
> Jeroen Mostert wrote: > > This group is for questions about the Common Language Framework in general.
> Heh. For "Framework", read "Runtime", obviously. I don't know what I'm > getting confused with, here.
> -- > J.
Will do in the future.
As for the issue, the funny thing is my memory was jogged when it was mentioned that outside of Win95/98/ME, the function was of limited use. I'd already came across the article that was linked, in fact. And then it dawned on me: One of my co-workers had uncommented that section of code and I, after having not seen the code for a couple months, just took it at face value. The fix was already in place using the modern .NET equivalent functions (Processes, ProcessInfo, etc.). Thanks again for your time and help!
btysgtma...@gmail.com wrote: > As for the issue, the funny thing is my memory was jogged when it was > mentioned that outside of Win95/98/ME, the function was of limited > use. I'd already came across the article that was linked, in fact. > And then it dawned on me: One of my co-workers had uncommented that > section of code and I, after having not seen the code for a couple > months, just took it at face value.
Behold the dangers of leaving in commented-out code. Although I've had a hard time with in the past myself, I've since become quite confident about deleting code that's no longer used, instead of keeping it around "in case anyone ever needs it". No matter how much time it took to develop, if it's no longer contributing to the solution now, it's just a maintenance burden.
> The fix was already in place using the modern .NET equivalent functions > (Processes, ProcessInfo, etc.). Thanks again for your time and help!
No problem, I got a chance to brush up on my VB syntax. Haven't used it in a while, since my fellow programmers are C# only, and they make me march to the beat of their drums. Apparently, they're just too *smart* to read VB.NET code. >:-)
-- J. Before C#, before Java, before C++, before C, there was BASIC
