Check result of call into Windows API

  • Thread starter Thread starter Lee
  • Start date Start date
L

Lee

(I also posted this query in Microsoft.Public.DotNet.Framework
yesterday, but since I have received no responses, I am posting it here
too.)

Using Windows XP with all updates applied and Visual Studio 2.0.

I am trying to develop some common error-handling of Windows API
invocations that fail and am using MessageBeep as the API to test with.

Given 1) the following Imports statement:

Imports System.Runtime.InteropServices

2) the following declaration of MessageBeep:

<DllImport("user32.dll", _
EntryPoint:="MessageBeep", _
SetLastError:=True, _
CallingConvention:=CallingConvention.StdCall)> _
Public Function MessageBeep(ByVal wType As Int32) As Boolean
End Function

3) the following code to test passing an invalid value to MessageBeep

Dim MBResult As Boolean
Dim MBErrorCode As Integer

MBResult = MessageBeep(-2)

If MBResult Then
MBErrorCode = Marshal.GetLastWin32Error
End If

When I set a break-point after the assignment to MBErrorCode, I see
that it has a value of 127 -- "The specified procedure could not be
found". I was expecting a value of 87 -- "The parameter is incorrect".

Note that when I pass MessageBeep a value of 0 -- a presumably valid
value -- I get the same result.
 
Lee said:
(I also posted this query in Microsoft.Public.DotNet.Framework
yesterday, but since I have received no responses, I am posting it here
too.)

Using Windows XP with all updates applied and Visual Studio 2.0.

I am trying to develop some common error-handling of Windows API
invocations that fail and am using MessageBeep as the API to test with.

Given 1) the following Imports statement:

Imports System.Runtime.InteropServices

2) the following declaration of MessageBeep:

<DllImport("user32.dll", _
EntryPoint:="MessageBeep", _
SetLastError:=True, _
CallingConvention:=CallingConvention.StdCall)> _
Public Function MessageBeep(ByVal wType As Int32) As Boolean
End Function

3) the following code to test passing an invalid value to MessageBeep

Dim MBResult As Boolean
Dim MBErrorCode As Integer

MBResult = MessageBeep(-2)

If MBResult Then
MBErrorCode = Marshal.GetLastWin32Error
End If

When I set a break-point after the assignment to MBErrorCode, I see
that it has a value of 127 -- "The specified procedure could not be
found". I was expecting a value of 87 -- "The parameter is incorrect".

Note that when I pass MessageBeep a value of 0 -- a presumably valid
value -- I get the same result.
Click to expand...

Lee - MessageBeep is probably not a good choice for this. From the
remarks section of the MSDN help:

If it cannot play the specified alert sound, MessageBeep attempts to
play the system default sound.
Click to expand...

What that means is that this function won't really fail for an invalid
value - it will simply play the system default sound. And that is what
it does on my system, it plays the sound even with an invalid value and
the function returns true.
 
Tom:

Thanks for the feed-back.

I guess I mis-interpreted the docs and thought that an invalid value
would cause MessageBeep to fail.

I'll try a different API function and post my results here.

--
// Lee Silver
// Information Concepts Inc.
//
// Converting Data into Information since 1981


Tom said:
Lee said:
(I also posted this query in Microsoft.Public.DotNet.Framework
yesterday, but since I have received no responses, I am posting it here
too.)

Using Windows XP with all updates applied and Visual Studio 2.0.

I am trying to develop some common error-handling of Windows API
invocations that fail and am using MessageBeep as the API to test with.

Given 1) the following Imports statement:

Imports System.Runtime.InteropServices

2) the following declaration of MessageBeep:

<DllImport("user32.dll", _
EntryPoint:="MessageBeep", _
SetLastError:=True, _
CallingConvention:=CallingConvention.StdCall)> _
Public Function MessageBeep(ByVal wType As Int32) As Boolean
End Function

3) the following code to test passing an invalid value to MessageBeep

Dim MBResult As Boolean
Dim MBErrorCode As Integer

MBResult = MessageBeep(-2)

If MBResult Then
MBErrorCode = Marshal.GetLastWin32Error
End If

When I set a break-point after the assignment to MBErrorCode, I see
that it has a value of 127 -- "The specified procedure could not be
found". I was expecting a value of 87 -- "The parameter is incorrect".

Note that when I pass MessageBeep a value of 0 -- a presumably valid
value -- I get the same result.
Click to expand...

Lee - MessageBeep is probably not a good choice for this. From the
remarks section of the MSDN help:

If it cannot play the specified alert sound, MessageBeep attempts to
play the system default sound.
Click to expand...

What that means is that this function won't really fail for an invalid
value - it will simply play the system default sound. And that is what
it does on my system, it plays the sound even with an invalid value and
the function returns true.
Click to expand...
 
Per Tom's suggestion I changed my test to use the GetTempFileName and
got the same result. My changes were as follows:

1)

<DllImport("kernel32.dll", _
EntryPoint:="GetTempFileNameA", _
CharSet:=CharSet.Ansi, _
ExactSpelling:=True, _
CallingConvention:=CallingConvention.StdCall)> _
Public Function GetTempFileName(ByVal Path As String, _
ByVal PrefixString As String, _
ByVal Unique As Integer, _
ByVal TempFileName As
Text.StringBuilder) As Integer
End Function

and 2)

Dim GTFName As New Text.StringBuilder(255)
Dim GTFResult As Integer
Dim GTFErrorCode As Integer

GTFResult = GetTempFileName("x:\temp" & Chr(0), _
"zzzz" & Chr(0), _
0, _
GTFName)
If GTFResult = 0 Then
GTFErrorCode = Marshal.GetLastWin32Error
End If


GTFResult is 0 (failure) after the call to GetTempFileName, and
GTFErrorCode is 127. Note that I am forcing an error because "x:\temp"
does not exist (I have no X drive), but the error-code seems to be
wrong.

--
// Lee Silver
// Information Concepts Inc.
//
// Converting Data into Information since 1981
Tom:

Thanks for the feed-back.

I guess I mis-interpreted the docs and thought that an invalid value
would cause MessageBeep to fail.

I'll try a different API function and post my results here.

--
// Lee Silver
// Information Concepts Inc.
//
// Converting Data into Information since 1981


Tom said:
Lee said:
(I also posted this query in Microsoft.Public.DotNet.Framework
yesterday, but since I have received no responses, I am posting it here
too.)

Using Windows XP with all updates applied and Visual Studio 2.0.

I am trying to develop some common error-handling of Windows API
invocations that fail and am using MessageBeep as the API to test with.

Given 1) the following Imports statement:

Imports System.Runtime.InteropServices

2) the following declaration of MessageBeep:

<DllImport("user32.dll", _
EntryPoint:="MessageBeep", _
SetLastError:=True, _
CallingConvention:=CallingConvention.StdCall)> _
Public Function MessageBeep(ByVal wType As Int32) As Boolean
End Function

3) the following code to test passing an invalid value to MessageBeep

Dim MBResult As Boolean
Dim MBErrorCode As Integer

MBResult = MessageBeep(-2)

If MBResult Then
MBErrorCode = Marshal.GetLastWin32Error
End If

When I set a break-point after the assignment to MBErrorCode, I see
that it has a value of 127 -- "The specified procedure could not be
found". I was expecting a value of 87 -- "The parameter is incorrect".

Note that when I pass MessageBeep a value of 0 -- a presumably valid
value -- I get the same result.
Click to expand...

Lee - MessageBeep is probably not a good choice for this. From the
remarks section of the MSDN help:

If it cannot play the specified alert sound, MessageBeep attempts to
play the system default sound.
Click to expand...

What that means is that this function won't really fail for an invalid
value - it will simply play the system default sound. And that is what
it does on my system, it plays the sound even with an invalid value and
the function returns true.
Click to expand...
Click to expand...
 
Lee said:
Per Tom's suggestion I changed my test to use the GetTempFileName and
got the same result. My changes were as follows:

1)

<DllImport("kernel32.dll", _
EntryPoint:="GetTempFileNameA", _
CharSet:=CharSet.Ansi, _
ExactSpelling:=True, _
CallingConvention:=CallingConvention.StdCall)> _
Public Function GetTempFileName(ByVal Path As String, _
ByVal PrefixString As String, _
ByVal Unique As Integer, _
ByVal TempFileName As
Text.StringBuilder) As Integer
End Function

and 2)

Dim GTFName As New Text.StringBuilder(255)
Dim GTFResult As Integer
Dim GTFErrorCode As Integer

GTFResult = GetTempFileName("x:\temp" & Chr(0), _
"zzzz" & Chr(0), _
0, _
GTFName)
If GTFResult = 0 Then
GTFErrorCode = Marshal.GetLastWin32Error
End If


GTFResult is 0 (failure) after the call to GetTempFileName, and
GTFErrorCode is 127. Note that I am forcing an error because "x:\temp"
does not exist (I have no X drive), but the error-code seems to be
wrong.
Click to expand...

Looking at this and your last example, I realize what the problem is...
You aren't adding the SetLastError:=True to your DllImport attribute.
Without that, the api error code is not saved.

Now for a couple of api suggestions...

1) You don't need to null terminate your strings (the Chr(0)), the
marshaller will take care of that for you. That was true in VB6 as
well as .NET. It won't hurt anything really, but it is just extra
overhead that doesn't need to happen.

2) Don't hard code to the A/W versions of your calls. The runtime
marshaller can work that out for you as well. In other words, your
declare would look like:

<DllImport("kernel32", CharSet:=CharSet.Auto, SetLastError:=True)>
_
Private Function GetTempFileName( _
ByVal lpPathName As String, _
ByVal lpPrefixString As String, _
ByVal uUnique As Integer, _
ByVal lpTempFileName As StringBuilder) As Integer

End Function

The runtime will call the W function on systems were it is available,
avoiding the extra string conversions required for the A function on NT
boxes.

3) Why don't you just use the VB declare syntax?
Private Declare Auto Function GetTempFileName Lib "kernel" (.....) As
Integer
That will set all the necessary attribute fields (like SetLastError).

Don't take any of the above as critizism, just friendly advice. Anyway
here is my code for your example:

Option Explicit On
Option Strict On

Imports System
Imports System.Text
Imports System.ComponentModel
Imports System.Runtime.InteropServices

Module Module1

<DllImport("kernel32", CharSet:=CharSet.Auto, SetLastError:=True)>
_
Private Function GetTempFileName( _
ByVal lpPathName As String, _
ByVal lpPrefixString As String, _
ByVal uUnique As Integer, _
ByVal lpTempFileName As StringBuilder) As Integer
End Function

'Private Declare Auto Function GetTempFileName Lib "kernel32" ( _
' ByVal lpPathName As String, _
' ByVal lpPrefixString As String, _
' ByVal uUnique As Integer, _
' ByVal lpTempFileName As StringBuilder) As Integer

Sub Main()
Dim tempFile As New StringBuilder(260)

If GetTempFileName("x:\temp", "zzzz", 0, tempFile) = 0 Then

Dim exception As New
Win32Exception(Marshal.GetLastWin32Error())
Console.WriteLine( _
"The error code was {0} and the message was {1}", _
exception.ErrorCode, exception.Message)

End If
End Sub
End Module
 
Tom:

Much much thanks for the help and advice.

1) The missing "SetLastError" was a brain fart on my part :) -- once I
added that, things worked as expected.

2) I wasn't sure about the Chr(0)'s -- but I figured better safe than
sorry. Glad they are not needed.

3) I did decide to change the declaration syntax to the shorter Declare
syntax -- I'm not sure why I was using the empty-function syntax -- but
the Declare syntax works just fine.

Thanks again for the help and advice.
 
Back
Top