Notes tests. ByVal ByRef Application.Run.OnTime Multiple Variable Arguments ByRef ByVal

[DocAElstein]

Slightly extended explanations
ByVal ByRef, and variables
Part 1 Simple variable Long type]

For more detailed background, See also here
https://www.excelfox.com/forum/showt...age3#post11882
https://www.excelfox.com/forum/showt...ll=1#post17881
We give here the simple explanation for ByRef / ByVal issues in VBA. but slightly different in that we are less concerned in considering resulting variable values, but rather the values of all pointer associated with the variables concerned in the example coding
Consider the 12 labelled code lines, those with the code line numbers) associated with the following coding. Those lines are done sequentially when we run the first main coding, Sub ByValByRefWithPointersLong()
(If anything is unclear about how the pointer values discussed are obtained, you should refer to the two references above )

Sub ByValByRefWithPointersLong()
1 Dim Lng As Long
2 Debug.Print VarPtr(Lng), VarPtr(ByVal Lng) '  '    1831204       0 
3 Call ByRefLong(Lng) ' Do a  ByRef  Call --#
7 Debug.Print VarPtr(Lng), VarPtr(ByVal Lng)    '    1831204       2

8 Let Lng = 0

9 Call ByValLong(Lng) ' Do a  ByVal  Call --**
13 Debug.Print VarPtr(Lng), VarPtr(ByVal Lng)  '     1831204       0
End Sub
Sub ByRefLong(ByRef Lnge As Long) ' #-- Do a  ByRef  Call
4 Debug.Print VarPtr(Lnge), VarPtr(ByVal Lnge)  '    1831204       0
5 Let Lnge = 2
6 Debug.Print VarPtr(Lnge), VarPtr(ByVal Lnge)   '   1831204       2
End Sub
Sub ByValLong(ByVal Lnge As Long) ' **-- Do a  ByVal  Call
10 Debug.Print VarPtr(Lnge), VarPtr(ByVal Lnge)  '   1831192       0 
11 Let Lnge = 2
12 Debug.Print VarPtr(Lnge), VarPtr(ByVal Lnge)  '   1831192       2
End Sub

Code line 1: Lng is strictly speaking the symbol for the pointer held in a stack of active variable that we don’t have easy access to, going by the name of Common Object File Format ( COFF ) symbol table, and could perhaps be by a layman be regarded as some sort of stack or shelf arrangement populated by some complex rules allowing software to access as necessary. Our interest starts at what is "in" this, in other words the number held at this stack/shelf location . It is a number which is made with 4 bytes, (32 bits). It, or the mechanisms associated with it, is/are called a Pointer, often.
The actual number refers to the first memory address ( the first memory address at the left hand side) of 4 Bytes (32 bits) set aside in memory to hold the final value which I later assign to the variable. In other words, where the first 0/1 value Bit is in the binary representation of a number is. This address is obtained by the first half of code line 2
I use for this explanation the numbers I got , you will of course get similar sized but different numbers. – Your computer will find an appropriate suitable place at the time you run the coding
This next sketch is a pictorial representation of that number in that mysterious shelf/stack (COFF symbol Table)
https://i.postimg.cc/RCXmK1wN/First-...able-value.jpg

We cannot easily know "where that sketch is".
The second value at line 2 tells us what number is held at that address. At this stage it will be 0 as the memory location and following 31 bits all have the value 0, representing the final decimal value of 0. At this stage those 32 bits have just been set aside for us to use.
This next sketch is similar to the last, as it is representing a similar sized memory location, ( 32 consecutive bits ). But this is a different "”place" / memory location , the one being "pointed to" by that number, 1831204 , in that shelf/stack (COFF symbol Table) . This place is being used currently to represent a value of zero, which it will be set to by default when it is set aside for us to use. We know "where this is". It starts at memory location 1831204, and ends 31 bits (4 bytes), further along at 1831204 + 3 = 1831207
https://i.postimg.cc/J0mxTCLL/Memeoy...ng-value-0.jpg


Code Line 4 in the first Called procedure returns the same values as code line 2. This is because the code lines are the same, and, importantly for our discussions, they are referring to the same variable, the same "place" depicted above. This is arranged by the use of ByRef in the Called Sub ByRefLong(ByRef Lnge As Long) We could think in simple layman terms, that in the first main procedure, Sub ByValByRefWithPointersLong() and the first Called procedure , the variables Lng and Lnge are in effect the same variable.
Code line 5 in the first Called procedure, then changes the value in the 32 bits there to a binary set of 0/1 digits representing the decimal value of 2. So not much has changed there: This is what it looks like now:
https://i.postimg.cc/6q00gbWG/Memeoy...ng-value-2.jpg


Just to make that all clear again, the story so far:
VarPtr(Lng) has returned us the number held in some place we do not have easy access to. That number , 1831204 , is the memory address of the first bit on the left of 32 bits reserved for us to hold the actual final value that we want to "have in the variable"
VarPtr(ByVal Lng) gives us the decimal value held in those 32 bits at any time. Originally it was set by default to zero, and at some point we changed it to 2

As we now move on, back in the main procedure. at code line 7, the two values returned remain at the values obtained / last set, within the first Called procedure: These are now the values as they stand in the main procedure: the address location of our original variable will never change as long as the coding runs, but we changed the value effectively at that address within the first Called procedure, - we were able to do that change to the value of 2 as effectively, in simple terms, Lng and Lnge were the same variable.

(Code line 8 takes the value of our variable,( that is to say the value represented by the 32 bits starting at memory location 1831204), back to 0 so that we can now repeat the same experiment using the second Called procedure, Sub ByValLong(ByVal Lnge As Long) )

Code line 10 tells us we "have a new variable” , with the name Lnge , which might sometimes be referred to as a local variable, - in this case it is local to the second Called procedure: The use of ByVal in Sub ByValLong(ByVal Lnge As Long) means that we take a value of, in this example 0, and , as in any Long value, we know it must be held somewhere. It cannot be held in 32 bits starting from memory location 1831204, since we are already using this for Lng in the main procedure. The computer has arranged another address for us, and as expected. It is not too far away as I was doing not much else on my computer that might need such a memory space. It has given me 1831192 and the value represented in the 32 bits starting there I currently have the decimal value of 0
Code line 11 sets the decimal value there to 2, as confirmed by code line 12

Finally we are back in our main procedure and do a last check with code line 13 of the situation to our original variable Lng. It has not been effected in any way by the second Called procedure, and remains in the state we left it in, when we went to the second
Called procedure. (Line 8 set it to 0 )

---

The next sketch shows the situation as it would be in at typical situation in a coding with a long variable declared, for example after
Dim Lng As Long
Let Lng = 2
https://i.postimg.cc/rpVP5Dm5/Final-...th-value-2.jpg





For comparison, here is the situation just before our coding ends, where we have our variable, but have "cleared" it so to speak, with = 0 , that is to say got it down to its "minimum" computer storage.
https://i.postimg.cc/G2DbWSp1/Final-...th-value-0.jpg


We note finally that for the case of a Long type, the computer storage used is identical, as the sketches perhaps suggest. In other words, from the computers point of view, an assignment of Let Lng = x, ( where x could be a small or a very large number ) , makes no significant difference to its memory state, and no difference at all to its memory allocation


_.___

One last short interesting experiment. It may not always work for you, but if you run the following short coding immediately after running the last coding, then it may work. We note that in the last experiments I mostly got a result of1831204 for the memory location of the start of the 32 bits that were made available to hold our Long variable number. The exception was when I ran Sub ByValLong(ByVal Lnge As Long) , and we got a different number, 1831192
We noted that this may have been because the number 1831204 was in use already. The following small coding only Calls that Sub ByValLong(ByVal Lnge As Long)
You may often find as I did , that it returns the same memory location as first obtained and mostly obtained in the last coding. This goes half way to supporting our ideas, as this makes sense as we do not make any attempt to get such a number/memory location reserved, until in the Sub ByValLong(ByVal Lnge As Long)

Sub OnlyByValCall()
Call ByValLong(0)
End Sub
' 1831204       0
' 1831204       2