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