Declare parameter name start with "p" ?

[**Developer**]

Notice below I sometimes used the "A" version. I found by cut-and-try that
only the "A" version would work correctly. Anyone have a suggestion of why
the "W" version would not work correctly?

One reason is that the ByRef or ByVal does not show by InteliSence so the
"p" would help there.

------

Secondly, I'd like to be consistent with the parameter names. I'd like to
precede with a "p" if ByRef or if a pointer is expected, whichever make more
sense.

Which is better to use?

If a string is passed by value should the variable strat with a "p"?

What about an IntPrt variable?

It would be a good example if someone would fix the parameter names below.

----------

Thanks a lot for any help here!



Public Declare Function OpenPrinter Lib "winspool.drv" Alias "OpenPrinterA"
(ByVal pPrinterName As String, ByRef phPrinter As IntPtr, ByRef pDefault As
WinSpool.PRINTER_DEFAULTS) As Integer

Public Declare Auto Function GetDefaultPrinter Lib "winspool.drv" (ByVal
pszBuffer As String, ByRef pcchBuffer As Integer) As Boolean

Public Declare Function SetPrinter Lib "winspool.drv" Alias "SetPrinterA"
(ByVal hPrinter As IntPtr, ByVal level As Integer, ByVal pPrinter As IntPtr,
ByVal cmd As Integer) As Integer

Public Declare Function GetPrinter Lib "winspool.drv" Alias "GetPrinterA"
(ByVal hPrinter As IntPtr, ByVal level As Integer, ByVal pPrinter As IntPtr,
ByVal cbBuf As Integer, ByRef pcbNeeded As Integer) As Integer

Public Declare Function DocumentProperties Lib "winspool.drv" Alias
"DocumentPropertiesA" (ByVal hwnd As IntPtr, ByVal hPrinter As IntPtr,
<MarshalAs(UnmanagedType.LPStr)> ByVal pDeviceName As String, ByVal
pDevModeOutput As IntPtr, ByVal pDevModeInput As IntPtr, ByVal fMode As
Integer) As Integer

Public Declare Auto Function ClosePrinter Lib "winspool.drv" (ByVal hPrinter
As IntPtr) As Integer

 

[Robin Tucker]

Personally, whenever I'm declaring external methods like this, I use the
same naming convention of the external target, rather than any vb
conventions. This makes it easier when looking things up in the target
documentation.

 

[Herfried K. Wagner [MVP]]

Notice below I sometimes used the "A" version. I found by cut-and-try that
only the "A" version would work correctly. Anyone have a suggestion of why
the "W" version would not work correctly?

One reason is that the ByRef or ByVal does not show by InteliSence so the
"p" would help there.

------

Secondly, I'd like to be consistent with the parameter names. I'd like to
precede with a "p" if ByRef or if a pointer is expected, whichever make
more sense.

I would use the original parameter names for function 'Declare's.

Public Declare Function DocumentProperties Lib "winspool.drv" Alias
"DocumentPropertiesA" (ByVal hwnd As IntPtr, ByVal hPrinter As IntPtr,
<MarshalAs(UnmanagedType.LPStr)> ByVal pDeviceName As String, ByVal
pDevModeOutput As IntPtr, ByVal pDevModeInput As IntPtr, ByVal fMode As
Integer) As Integer

\\\
Public Declare Auto Function DocumentProperties lib "winspool.drv" (
ByVal hWnd As IntPtr, _
ByVal hPrinter As IntPtr, _
ByVal pDeviceName As String, _
ByRef pDevModeOutput As DEVMODE, _
ByRef pDevModeInput As DEVMODE, _
ByVal fMode As Int32 _
) As Int32
///

 

[**Developer**]

Suppose you had to pass an integer ByRef?

How about a pointer to a buffer (array of bytes)

Thanks a lot

 

[**Developer**]

Personally, whenever I'm declaring external methods like this, I use the
same naming convention of the external target, rather than any vb
conventions. This makes it easier when looking things up in the target
documentation.

I wouldn't be supprised if I find in most instances they use "p" where I'll
use "p"

Thanks

 

[Herfried K. Wagner [MVP]]

Suppose you had to pass an integer ByRef?

How about a pointer to a buffer (array of bytes)

Can you show a sample?

 

[**Developer**]

Thanks for asking.
Below are three samples.

Can you show a sample?

What to name the two Params?
Public Declare Auto Function SendMsgRef Lib "user32.dll" Alias "SendMessage"
(ByVal hWnd As IntPtr, ByVal msg As Integer, ByRef wParam As Integer, ByRef
lParam As Integer) As Integer

USAGE

SendMsgRef(hWndRichTextBox, EM_GETZOOM, lNumerator, lDenominator)







I looked and there all gone!!
Guess they have all been changed to string buffers!

What to name lpLCData (used for lBuf)

Public Declare Auto Function GetLocaleInfo Lib "kernel32" (ByVal locale As
Integer, ByVal lCType As Integer, _

<[In](), MarshalAs(UnmanagedType.LPWStr)> ByVal lpLCData As String, ByVal
cchData As Integer) As Integer

USAGE

Public Shared Function LocaleInfo(ByVal lCID As Integer, ByVal type As
Integer, ByVal typeMsg As String) As String

Dim lBuf As String

Dim lRet As Integer

lRet = GetLocaleInfo(lCID And &HFFFF, type, Nothing, 0)

If (lRet = 0) Then

MessageBox.Show(GDI.UserError(VB.Err.LastDllError), typeMsg,
MessageBoxButtons.OK, MessageBoxIcon.Exclamation)

End If

lBuf = VB.Space(lRet)

GetLocaleInfo(lCID And &HFFFF, type, lBuf, VB.Len(lBuf))

LocaleInfo = GDI.TrimToNull(lBuf) & VB.vbTab & typeMsg & vbCrLf

End Function








What to name pszBuffer (lBuf)
What to name pcchBuffer (lLen)


Public Declare Auto Function GetDefaultPrinter Lib "winspool.drv" (ByVal
pszBuffer As String, ByRef pcchBuffer As Integer) As Boolean

Public Shared Function GetDefaultPrinterDeviceName() As String

Dim lBuf As String

Dim lLen As Integer

Dim lPrinter As Integer

lLen = 1024

lBuf = VB.Space(1024)

If WinSpool.GetDefaultPrinter(lBuf, lLen) Then

GetDefaultPrinterDeviceName = VB.Left(lBuf, VB.InStr(lBuf, VB.Chr(0)) -
1).Trim

Else

GetDefaultPrinterDeviceName = ""

End If

End Function