>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).
Mattias

Signature
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Ben Voigt [C++ MVP] - 10 Jan 2008 17:40 GMT
> >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).
Also the character set needs to be specified.
> Mattias
> 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.

Signature
J.
Jeroen Mostert - 10 Jan 2008 19:37 GMT
> 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.

Signature
J.
btysgtmajor@gmail.com - 10 Jan 2008 20:18 GMT
> > This group is for questions about the Common Language Framework in general.
>
[quoted text clipped - 3 lines]
> --
> 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!
Jeroen Mostert - 10 Jan 2008 22:30 GMT
> 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. >:-)

Signature
J.
Before C#, before Java, before C++, before C, there was BASIC