….continued from last post
So in the coding we are now in the main coding just before code line 8.
In the corresponding line in the Long case, we did Let Lng = 0 here, the purpose of which was to get us back to the situation of the variable at the point after the Dim
Code:
Sub ByValByRefWithPointersString() ' https://www.excelfox.com/forum/showthread.php/2404-Notes-tests-ByVal-ByRef-Application-Run-OnTime-Multiple-Variable-Arguments-ByRef-ByVal?p=11889&viewfull=1#post11889
1 Dim strOb As String
2 Debug.Print VarPtr(strOb), VarPtr(ByVal strOb), StrPtr(strOb), StrPtr(ByVal strOb) ' 1831204 0 0 0
3 Call ByRefString(strOb) ' Do a ByRef Call --#
7 Debug.Print VarPtr(strOb), VarPtr(ByVal strOb), StrPtr(strOb), StrPtr(ByVal strOb) ' 1831204 86412692 86412692 86412692
8 Let strOb = vbNullString
9 Call ByValString(strOb) ' Do a ByVal Call --**
13 Debug.Print VarPtr(strOb), VarPtr(ByVal strOb), StrPtr(strOb), StrPtr(ByVal strOb) ' 1831204 0 0 0
End Sub
Sub ByRefString(ByRef strObs As String) ' #-- Do a ByRef Call
4 Debug.Print VarPtr(strObs), VarPtr(ByVal strObs), StrPtr(strObs), StrPtr(ByVal strObs) ' 1831204 0 0 0 0 0
5 Let strObs = ""
6 Debug.Print VarPtr(strObs), VarPtr(ByVal strObs), StrPtr(strObs), StrPtr(ByVal strObs) ' 1831204 86412692 86412692 86412692
End Sub
Sub ByValString(ByVal strObs As String) ' **-- Do a ByVal Call
10 Debug.Print VarPtr(strObs), VarPtr(ByVal strObs), StrPtr(strObs), StrPtr(ByVal strObs) ' 1831036 0 0 0
11 Let strObs = ""
12 Debug.Print VarPtr(strObs), VarPtr(ByVal strObs), StrPtr(strObs), StrPtr(ByVal strObs) ' 1831036 86412092 86412092 86412092
End Sub
The last thing we discussed in the last post was the code line Let strObs = "" , and one conclusions was that the use of = "" does not return us to the state after the Dim, in the same or similar way that the = 0 did/ does in the long case.
vbNullString
This introduced for API things around the VB4 - VB5 time, and in VB6 and VBA it is "hidden". Quite a bit of debate and different opinions seem to be about it, perhaps as often as few people, if any, really know for sure. For our current discussions it seems to put us back to the state after the Dim
To quickly demonstrate that pictorially, here some sketch pairs, on the left some we had before, and on the right the change caused if we applied vbNullString to the variable

Areas-likely-to-change-on-string-value-assignment.jpg Areas-likely-to-change-on-string -value-assignment after vb NullString.jpg
Let-str-Ob-A.jpg Let-str-Ob-A after vbNullString.jpg
The sketches on the right represent the exact situation after the Dim
_.____-
So, after code line 8, Let strOb = vbNullString , we are back to the initial start position so as to move on to the ByRef ByVal issues. Having covered the ByRef case we move on to the ByVal
The signature line , ByVal strObs As String , in the second Called routine, Sub ByValString(ByVal strObs As String) effectively gives us a new string type variable, strObs, as demonstrated by the next code line 10 which is giving us the number in the COFF, which for the first time we see has changed from that previously. In my ran example, I had until now always got 1831204 but now I have got 1831036. We expect this as our computer still has the address 1831204 in use, as it were, in the main coding, Sub ByValByRefWithPointersString()
We see perhaps a more noticeable difference in the two numbers, compared to the long case. This is perhaps understandable as there is more uncertainty in the final memory space that might be needed. (In the long case it was known that we would need no more than another 4Bytes, 32 Bits, so the next variable could be given a value not far from the last.)
We use again the example string "" ain the variable assignment in code line11, Let strObs = ""
Code line 12 the gives expected results of the previous COFF number and now also a new, the other "pointer" value, a unique one not yet used
Finally back in the main routine, we confirm in code line 13 that nothing done in this second Called routine, Sub ByValString(ByVal strObs As String), had any effect on the strOb variable of the main routine
So the conclusion is that both Long and String type variables behave similarly in terms of the ByRef ByVal issues in Called procedures. However we have seen that we need to have a good understanding to the memory location handling, and difference in the two types in order to interoperate the results correctly.
Bookmarks