Gustav Brock
gustav at cactus.dk
Mon Oct 20 05:05:03 CDT 2003
Hi Stuart
Good idea. Except for one thing: sometimes ByVal is handled like ByRef
in API calls. I've never found an explanation for that ...
Here's an example (strBuffer):
Private Declare Function GetTempPath Lib "kernel32" Alias "GetTempPathA" ( _
ByVal nBufferLength As Long, _
ByVal lpBuffer As String) As Long
Public Function GetTempDirectory() As String
' Returns path to temp directory incl. traling backslash:
' c:\winnt\temp\
Const clngBufferLen As Long = 255
Dim lngPath As Long
Dim strBuffer As String * clngBufferLen
lngPath = GetTempPath(clngBufferLen, strBuffer)
If lngPath < 0 Then
lngPath = 0
End If
GetTempDirectory = LCase(Left(strBuffer, lngPath))
End Function
/gustav
> As an extension to that, I've started prefixing function parameters with the By
> Ref/By Val type. Eg Function CapString (By Val vstrSomeValue as string) as
> string. (vstr is string by value as opposed to rstr as by ref) Mostly this is
> just for accuracy of naming, but it could be useful if you manipulate the
> parameter, particularly in the case of API calls.
> You do raise a good point John. Variable naming conventions are meant to be
> useful in debugging, relooking at code, or just taking over someone elses code.
> I suppose you could extend a convention to handle cases like that.
> For example, I've seen.
> cstr string constant
> vstr string by value (I didn't invent this)
> rstr string by ref
> So why not add
> varstr/varint/varlng etc
> varstr variant expecting a string
> varlng variant expecting a long