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

**DocAElstein** · 02-09-2017, 02:39 PM

Post for reference from a few other places, such as
https://eileenslounge.com/viewtopic....322751#p322751
https://www.excelfox.com/forum/showt...php/2824/page2

ByRef ByVal and winapi
VBA variable basics
Variables, ByRef ByVal, "pointers" (Addresses)

The idea of this and the over next posts is to just very slightly extend the simplest typical explanation of ByRef and ByVal in VBA. This slightly extended explanation in the next post including an equally very slightly extended explanation of some VBA variables can, IMO, go a long way to help understand other issues later on when learning VBA: It is worth the effort in almost all cases, since the over simplified explanations can make further learning unnecessarily complicated.
The slightly fuller explanations can be particularly helpful in API work, and indeed these postings arise from my attempts to get a better understanding to the issues in this post: https://eileenslounge.com/viewtopic.php?f=30&t=41659
This first post revises the typical beginner explanation

ByRef ByVal
Review of typical explanation VBA ByRef ByVal

This is a typical simple explanation, and I will assume you know this. If you don’t then best learn it before you go any further
The TLDR:
ByRef and ByVal are instructions to VBA. They instruct whether to take the value (ByVal ), of a given variable ( "the original text" of/in the variable StrBuffa in this example ) or whether to refer to the variable, - crudely in this latter case, in Layman terms ByRef instructs to take the variable itself, rather than the value in it..

Simple sample coding

Code:

Sub MainRoutine_ByValByRefSimpleVBAFunctionsExample()     '     https://www.excelfox.com/forum/showthread.php/2404/page3#post11880
Dim StrBuffa As String
 Let StrBuffa = "the original text" '

Call TakeValue(StrBuffa)     ' Take the value in  StrBuffa  into  Sub TakeValue(ByVal Tecst As String)
Debug.Print StrBuffa ' : MsgBox StrBuffa
Debug.Print

Call TakeVariable(StrBuffa)  ' A bit like Taking the variable, StrBuffa,  into  Sub TakeVariable(ByRef Tecst As String)
Debug.Print StrBuffa ' : MsgBox StrBuffa
End Sub
Sub TakeValue(ByVal Tecst As String)
 Let Tecst = "a new value" ' This only does anything within this routine,  so it has no effect, for example, on anything in the main routune
End Sub
Sub TakeVariable(ByRef Tecst As String)
 Let Tecst = "a new value" ' This has the effect of changing the value of  StrBuffa  in ther main routine
End Sub

If you run the first, main routine above, Sub MainRoutine_ByValByRefSimpleVBAFunctions() , then this should be the output:

the original text

a new value

The first output ,
the original text
, received after the first Call, Call TakeValue(StrBuffa) , tells you that you (still) have the original text in a string variable, StrBuffa, which is at the start of the main routing , Sub MainRoutine_ByValByRefSimpleVBAFunctions()
, and the second output ,
a new value
, received after the second Call , Call TakeVariable(StrBuffa) , tells you that you have a new value in that original string variable. In other words in this latter case you changed the value in the original main coding variable, StrBuffa,

Simple layman Explanation
A simple laymen explanation is that in the first Call, Call TakeValue(StrBuffa), I put a value in a local variable, Tecst, in the second routine, Sub TakeValue[( … ). That’s it. There is no way inside that second subroutine to change the value in the original variable StrBuffa , of the main routine, Sub MainRoutine_ByValByRefSimpleVBAFunctions()

In the second Call , Call TakeVariable(StrBuffa) , I am arranging that I am referring to the variable StrBuffa, (from the main routine ), when in the third and final routine , Sub TakeVariable( …. ). So I can, and do, change its value, which is then what the second output tells me. - Inside Sub TakeVariable( …. ), any reference to Tecst is effectively referring to the original variable StrBuffa , from the main routine.
In other words, within the third and final routine , Sub TakeVariable, the variable Tecst can be thought of as not a local variable, but effectively the variable StrBuffa within the main routine, Sub MainRoutine_ByValByRefSimpleVBAFunctions()
Another simple layman way to think of that is that in the third and final routine, Sub TakeVariable( .. ), I take the variable from the main routine, StrBuffa, itself , into the third and final routine , not just the value inside it. In the second routine, Sub TakeValue( ..) , I just take the value.
I realise that all the above is not technically so correct. - Indeed the purpose of this and the next post is to give a slightly more technically correct explanation, but one that is still understandable by a beginner

ByRef and ByVal are instructions to VBA. They instruct whether to take the value (ByVal ), of a given variable ( StrBuffa in this example ) or whether to refer to the variable, - crudely in this latter case, in Layman terms ByRef instructs to take the variable itself.

(In these sort of coding arrangements, we may refer to the main routine as the Calling routine, and the others as the Called routines )

A useful consequence of the above: Use ByRef instead of function return value
This is also worth reviewing , while we are here.
Some of us will know that this latter ByRef way of taking a variable, is a way to effectively get values returned from a routine, or function, since variables like StrBuffa can be thought of as a Buffer ( Buffer = box, variable, place, shelf, pigeon hole etc), to take and hold values assigned within the Called routine.
In other words, it can be thought of as a trick to make a Called routine or Function work as if it was a function that can return more than one value**.

( ** A Function in VBA and other languages is generally regarded as something that can return a single value, we talk of "The function return value", which if x is the "The function return value", then it would typically be seen in coding as x = MyFunction( ….. ) )

Examples in the next post

**DocAElstein** · 02-09-2017, 04:43 PM

Use ByRef instead of function return value

Example coding:
In Rem 1 we make a call to two simple conventional Function coding examples . One returns the sum of two given numbers, and the other the difference of the same two numbers.
In Rem 2, we make a call to a function that once again takes in the same two nunbers, but makes no return itself. It additionally takes in ByRef two variables . Effectively then we fill those variables in the function, a coinsequence of effectivley filling the variables passed to the function.

Code:

Sub MainRoutine_MakeRoutineWorkLikeAFunctionReturningMultipleValues()
Dim NSum As Long, NDiff As Long  '    https://www.excelfox.com/forum/showthread.php/2404-Notes-tests-ByVal-ByRef-Application-Run-OnTime-Multiple-Variable-Arguments-ByRef-ByVal?p=11881&viewfull=1#post11881

Rem 1  Classic Function use in VBA
 Let NSum = SumNumbers(2, 1)
Debug.Print NSum
 Let NDiff = NumbersDifference(2, 1)
Debug.Print NDiff
Debug.Print

Let NSum = 0: NDiff = 0 '  Empty variables

Rem 2  Unconventional way in VBA to return more than one value from a function or Sub routine
 Call NumbersSumAndDifference(2, 1, NSum, NDiff)
Debug.Print NSum; NDiff

End Sub

Function SumNumbers(ByVal N1 As Long, ByVal N2 As Long) As Long
 Let SumNumbers = N1 + N2
End Function
Function NumbersDifference(ByVal N1 As Long, ByVal N2 As Long) As Long
 Let NumbersDifference = N1 - N2
End Function

Function NumbersSumAndDifference(ByVal N1 As Long, ByVal N2 As Long, ByRef TheSum As Long, ByRef TheDiff As Long)
 Let TheSum = N1 + N2: TheDiff = N1 - N2  ' Effectively the variable  TheSum  is the variable  NSum  from the main  calling routine, and similarly the variable  TheDiff  is  effectively the variable  NDiff  from the main calling routine 
End Function

, output should be

3
1

3 1

Notes:

_(i) ) In these sort of coding arrangements, we may refer to the main routine as the Calling routine, and the others as the Called routines or Called functions

_(ii)a) In this example, Function MainRoutine_MakeRoutineWorkLikeAFunctionReturningM ultipleValues ( ..….. , as it is written, can be a Function , (as it indeed is), but it can also be a Sub, by simply replacing Function with Sub

_(ii)b) For the function version only, you could also give another return in the conventional way by
_ adding a ..… ) As ..…. at the end of the function signature line in the conventional way
, and
_assigning the function name to something within the function, in the conventional way : Let MainRoutine_MakeRoutineWorkLikeAFunctionReturningM ultipleValues = …… )
Just to clarify this last point, the single called function in the following example is used both in the conventional and unconventional way to return in total 3 values: The same two values as the last coding, and an extra string value,
The two results are: The sum, 3 , and the difference, 1
That extra string value is returned in the conventional way.

Code:

Sub MainCallingRoutine()
Dim NSum As Long, NDiff As Long

Debug.Print NumbersSumAndDifference(2, 1, NSum, NDiff)
Debug.Print
Debug.Print NSum; NDiff

End Sub

Function NumbersSumAndDifference(ByVal N1 As Long, ByVal N2 As Long, ByRef TheSum As Long, ByRef TheDiff As Long) As String
 Let TheSum = N1 + N2: TheDiff = N1 - N2 ' Effectively the variable  TheSum  is the variable  NSum  from the main  calling routine, and similarly the variable  TheDiff  is  effectively the variable  NDiff  from the main calling routine
 Let NumbersSumAndDifference = "The two results are: The sum, " & TheSum & " , and the difference, " & TheDiff
End Function

The results are

The two results are: The sum, 3 , and the difference, 1

3 1

3 1 is obtained as in the previous example, and the string of text
, The two results are: The sum, 3 , and the difference, 1
, is returned from the called function in the more conventional way

Some performance characteristics of Using ByRef instead of function return value, (with strings)
As discussed, returning a value, such as a string, as the function return value, is the conventional practice. However, using the unconventional ByRef way to return a string in a ByRef parameter is faster.

It's often considered bad programming practice to return values in parameters. Normally procedures should not cause side-effects by modifying their ByRef parameters. But if performance is very important the ByRef trick is worth considering. If using ByRef for that reason I would perhaps write a ' comment to say so.

There is one case where ByRef is slower than ByVal. This happens when passing ByRef to an out-of-process server. The variable has to be marshalled twice, once going into the method and once returning. The implication is to use ByVal for your public server interfaces.*

(* https://www.aivosto.com/articles/stringopt2.html

In the next post we start again from basics , but assuming you understand this and the last post

**DocAElstein** · 02-09-2017, 04:46 PM

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

VBA variable examples: Simple and slightly complex variable examples
A program stores the value of variables somewhere in the main memory. Where and how this happens is usually completely irrelevant to us as VBA does all the heavy work for us. Never the less, a slightly more in depth knowledge is generally worth having, IMO, and in particular, if later getting involved with API stuff
In particular I am interested in extending the explanations to the so called "Pointer " things, which in simple terms is concerned with how many computer systems and languages handle addresses/ location indicators of memory locations involved in storing and handling/ retrieving variable values/contents
VBA variable examples: Simple variable example: Long
If you declare a variable of type Long, for example, the system assigns the variable a start address in memory, and from there four bytes, (32 binary Bits) are set aside to hold the number value . This allows a very large whole number range to be represented / stored, and for modern computers, 4 Bytes is a very small insignificant amount, so it is of no concern if the variable holds a large or small number, in other words it is of little concern if you need all the 32 Bits or not
Because VBA does all the heavy work for us, we can easily get mislead into thinking that the long type variable somehow has or holds the value. It never does. When we use the variable, VBA goes off and gets the value, and when presented to us it may appear as if it is there, for example when we hover over it in the VB editor , but it isn't. For the Long variable, it is probably more accurate to say it holds the start address…… the start address in memory, from where four bytes, (32 binary Bits) are set aside to hold the number value: This happens even if the variable has not yet been assigned a value; the declaration is sufficient. Just after the declaration, nothing is written into these four bytes and all the bits in them are still set to "0". The situation can be thought of as that it is just noted somewhere: "The value of the variable is stored from memory address 142008724". This "note" idea or concept is called a "pointer". Or saying the same thing slightly differently: a variable used to hold such an address is called a pointer. So the Long variable could be considered a pointer.
Pretty well most variables used in VBA can be considered such a pointer. In simple layman terms it makes sense : It is pointing to somewhere in a way of thinking: - VBA can be thought in running a coding to go there to get the address, to go to – a bit like asking someone where to go and they point you in the right direction, by giving you the address.
Now at this point it is easy to get confused, but with a bit of careful thinking things the confusion should go away: The variable itself, the thing containing the important address also has an address. As mentioned, VBA does all the hard work for us normally making everything seem simpler than it is: "Give it a variable", and it will find, use, and/ or show you the value as appropriate, leading you to think the variable "has" the value. But we have some tools that can be thought of as disabling the automatic VBA processes, and just return us something more raw, Pointer functions
Pointer Functions
There are a few, but we will only consider a couple for now.
VarPtr(variable name) As LongPtr
We can use this in a couple of ways. In the simplest form as shown it will give you the address of the variable you give it. Pseudo like
= get address of(This variable) : It does not tell you what is "in" the variable. It does not give you any value
For the case of a Long it will give you the address of that variable, not the address in memory, from where four bytes, (32 binary Bits) are set aside to hold the number value!
Now, these pointer functions are old functions, they are not only undocumented, but they are even hidden in the object catalogue. They are not VBA functions, so are, probably, external functions of a sort. Here is an important but not well known fact. External function calls are set by default to work in the ByRef way, but you can override this at the call. Depending on how such an old function is implemented/wired into, VBA, that override ability and other original things associated with such an old function may or may not still work. But experience shows the older things are in Microsoft the moiré likely they are to work more usefully. These functions are very old and indeed this override function seems to work. It works in the same way as we might generally expect for the ByVal as so far discussed.
In the coding below, in Rem 1, we use, twice, the VarPtr( ) to get
_a) the address of a long variable, (remember that will be the address of the pointer: The variable holding the address of where in memory the actual final wanted number value will be)
_b) using the ByVal option we can get the "value" at that memory address, but now it gets a bit subtle and complex, or rather it will when we consider a String type. For now, we see that we get the value of zero, since we have not "filled the variable"
In Rem 2 the same is done again after the variable is "filled" with a value

Code:

'         https://www.excelfox.com/forum/showthread.php/2404-Notes-tests-Application-Run-OnTime-Multiple-Variable-Arguments-ByRef-ByVal?p=11881&viewfull=1#post11881
Sub PoyntersVarialesAddresses()                                                   '   https://classicvb.net/tips/varptr/                 https://www.vba-tutorial.de/referenz/zeiger.htm
Rem 0 A simple vaiable, Long Type
Dim Lng As Long
Rem 1
Debug.Print "Rem 1"
'1a) ' Address of the Pointer; the actual typical wanted value
Debug.Print "Pointer Address; actual typical wanted value  ";
Debug.Print VarPtr(Lng); Lng
'1b) ' The value at that address; the actual typical wanted value"
Debug.Print "Value at address; actual typical wanted value  ";
Debug.Print VarPtr(ByVal Lng); Lng
Debug.Print
 Let Lng = 2
Rem 2
Debug.Print "Rem 2"
Debug.Print "Pointer Address; the actual typical wanted value  ";
Debug.Print VarPtr(Lng); Lng
Debug.Print "Value at address;the actual typical wanted value  ";
Debug.Print VarPtr(ByVal Lng); Lng
End Sub

The results are as expected
Rem 1
Pointer Address; actual typical wanted value 2749500 0
Value at address; actual typical wanted value 0 0

Rem 2
Pointer Address; the actual typical wanted value 2749500 2
Value at address;the actual typical wanted value 2 2

For more detailed pointer discussions, see here https://www.excelfox.com/forum/showt...ll=1#post17881

**DocAElstein** · 02-09-2017, 04:48 PM

Slightly extended explanations
ByVal ByRef, and variables
Part 2 less Simple variable String type

Characters are more complicated for a computer to store, ( https://www.excelfox.com/forum/showt...ll=1#post17877 ) and a lot of text can be extremely long, so desirably we would like this large amount to be available. Currently I think we are talking of sizes around a Giga Bytes or two. But we may not always need this. Unlike in the case of a Long variable type, it would be impractical to routinely set aside a very large amount of memory after/ with a Declaration. More commonly, the address gets assigned once a value is given, ( when the variable gets "filled" ). It is slightly more complicated in the case of VBA as the VBA variable will then contain the address of another pointer which is a specific pointer type, one originating from Visual Basic, sometime referred to as BSTR, (Binary String or Basic String, or a pointer of some sort . Immediately you have opened a can of worms as there is not generical agreement on what a BSTR is). This BSTR (pointer) "goes to" (has the address ("value in it") of), not the start of the memory location as was the case with the Long, but rather to the start of the section containing the representatio0n of the characters of the string. Unlike in the case of the Long, things other than the final value we are interested in , mainly the a length of the string, is also at the memory location.
(Attempting to lift the skirt of VBA and discuss things like VB Strings, and terms such as BSTR can be very dangerous.
I actually put this post, and the rest of this page, on hold and I made some attempt to clarify the situation in a forum Thread, ( https://eileenslounge.com/viewtopic.php?f=30&t=41784 ). A month later I am still not fully clued up on the situation, but am possibly almost as far as anyone has ever got, and can perhaps proceed, with caution, with this post. Complete clarity may require going 20-30 years retro with Microsoft and installing some earlier versions of the Visual Basic that is generally regarded as what most or VBA is based on. I can then cross check some experiments I have done in VBA).

At this point I have left the rest of this page 3, for some rough notes as I move on finally onto the next page 4

In particular, at this stage it is worth a look at some notes on Pointers, which I have put in a Thread considering API things, since pointers, in particular with string variables, are an important issue in API calls in VB(A)

Long
https://www.excelfox.com/forum/showt...ll=1#post17881
https://www.excelfox.com/forum/showt...age2#post17881

String
https://www.excelfox.com/forum/showt...ll=1#post24948
https://www.excelfox.com/forum/showt...age2#post24948

**DocAElstein** · 02-09-2017, 04:57 PM

**DocAElstein** · 02-09-2017, 04:58 PM

lvödsvdljv

**DocAElstein** · 02-09-2017, 05:05 PM

Taking a time out here to ask a question or two or 11 over at Eileen's Lounge
https://eileenslounge.com/viewtopic....323893#p323893
https://eileenslounge.com/viewtopic....323894#p323894

Here is the two post in one…….

Hi
I have been going around in circles on this one for a few days, and I am still not sure if I have quite got it right.
Can someone help put me out of my misery by confirming some things or otherwise….

First, I think I do understand approximately how a VBA Long type variable and a VBA String type variable are handled in memory, and I think I understand the important differences in those two, ( and why) , in the way they are handled and stored. My confusion is related to exactly which memory addresses are being referred to in the following coding examples

Long example

Code:

Sub ConfusedWithVBALongTypeMemoryStuff()
1 Dim Lng As Long
2 Debug.Print VarPtr(Lng)        '  2355700    I don't know where this number is held in memory. I don't care
3 Debug.Print VarPtr(ByVal Lng)  '  0
4 Debug.Print Lng                '  0
 
 Let Lng = 2

5 Debug.Print VarPtr(Lng)          '  2355700
6 Debug.Print VarPtr(ByVal Lng)    '  2

8 Debug.Print Lng                  '  2
End Sub

In the first line of the coding above, Dim Lng As Long , Lng becomes a number which is made with 4 bytes, (32 bits). It is called a Pointer. 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, (with Let Lng = 2 ). In other words, the act of doing Dim Lng As Long reserves for me 4 sequential memory addresses/ byte locations, in a sequential row as it were. And the first one, the first byte, at the left as it were, has the memory location got for me with the second code line, Debug.Print VarPtr(Lng) (by me , I got the value shown in the ' comment - 2355700** )
Q1: Have I got that right?

The third line, Debug.Print VarPtr(ByVal Lng) , is perhaps giving me the same as the 4th line, which is the value of the variable. For the case of a Long Type it does have a value even before I assign one. It has the value 0. If I assigned it 0 with Let Lng = 0 nothing would change anywhere
Q2: Have I got that right?

In line 5 , the memory location has not changed, as it never does for the VBA Long type, even if I assign a much different number. This is because It doesn’t need to change, because 32 bits are enough to hold in binary any number in the range of the defined number range for a VBA Long type
Q3: Have I got that right?

Line 6 aqnd line 8: My results suggest that Debug.Print VarPtr(ByVal Lng) and Debug.Print Lng are giving me the same thing – the value it sees at the address, 2355700**.
Q4: Any comments at all on that?
( **The address I got was 2355700 , you will get a similar but different number. I am OK with that and understand why that is )

This next bit is what has got me a bit confused. The 32 Bit number, the number returned from the second code line, Debug.Print VarPtr(Lng) , (by me 2355700** ) , is presumably held somewhere in memory as well? Where I don't know (I am not complaining, I just am trying to confirms that I got that right). I know the value held there, (by me 2355700** ) , but I don’t know where that number is being held
Q5: Have I got that right? (I expect VarPtr( ) knows that memory location as it goes there and gets the number in it for me. ( Maybe there is a "stack" of active variables and their values somewhere we ain't privy to?)

Q6: In this situation what is actually the "Pointer". Is it
_ the number the second code line, Debug.Print VarPtr(Lng) , gets me,
_ is it the variable Lng ,
_ is it the Bytes used for it somewhere I don't know?
Or is the word "pointer" some vague concept you would use to refer to one or more of those things or all of them depending on the context in which you use it

I have some similar questions on the VBA String type. It will perhaps help tidiness and later reference if I do another post for that…..

Ref: VarPtr , StrPtr stuff https://classicvb.net/tips/varptr/ , https://www.vba-tutorial.de/referenz/zeiger.htm

https://www.excelfox.com/forum/showt...age3#post11886

Unicorn or Unicode Encoding – A beast by any name

…….. continued, sort of, from last post

…. Confused with VBA and VB String Pointer Stuff

First, I do understand
_ (i) that String memory handling generally in computing, is a bit more dynamic/ complex than something like for a simple number, since even with modern computers, we don’t want to go around reserving a Giga Byte or two of memory every time we Declare a string variable.
and
_(ii) thanks to a lot of research and help from here, I am pretty well clued up now on all the various Ascii Ansi, Unicorns and other character encoding beasts roaming about ..

Once again my main confusion just now is/ was to do with what memory addresses / pointers are referring to what / where etc…

So, bearing that in mind…..
and with reference to the coding below….

After a month on and off researching VB String stuff, and VBA – VB API stuff, I was not too sure anymore that I even understood the very first line, Dim Str As String, … but as is often the case, preparing carefully the question can often help get the answer… The second code line Debug.Print VarPtr(Str) actually returned me the very same number as the second code line in the coding from the last post, Debug.Print VarPtr(Lng)!! I do realise that will not always be the case, but as I ran the coding shortly after running the previous coding on the same computer, then there is a chance it will be the same, as it was, … because….. how about this: What Dim Str As String in the coding below is doing, is very similar to what the Dim Lng As Long did/does in the coduing from the last post, - it sets aside once again 4 Bytes (32 bits) for me. But the difference being now is that it is not reserving me a place to store any final number or character values, rather it is reserving me a place … for …. a 32Bit Pointer , specifically a pointer to a VB String, (what I might refer to as a COM BSTR), and if I am feeling very adventurous I might say it’s a LPWSTR pointer, (or variation of) , which means that when it eventually gets filled in, it will be the address not of the start memory point I finally use for my string, but rather 4 Bytes along where the actual Unicode UTF-16 LE encoding Bytes start.
Q7. Have I got that right?

So I could say, what I have is a VBA Pointer to a VB Pointer, or perhaps a VBA Pointer to what likely will be a VB Pointer – depending on how you feel the word pointer should be used
Q8. Have I got that right?

The result 0 of code line 3 and code lines 4 are, I think, telling me the bit I think I know, -they are telling me that, unlike in the case of the Long I have not yet reserved any memory for my final character string.
Q9a) Have I got that right?

Q9b) This is a tricky one that might get me hate mail. I am sure many people would tell me that at this point my Str variable is a vbNullString. I don’t see that. I think I have nothing to do with a VB string at this point? All I have is an empty VBA 32 bit pointer, possibly even indistinguishable from a Long variable of value 0
Any comments on that?

Q9c) I am not too clear what the difference is in these 2(3) code lines.
VarPtr(ByVal Str)
StrPtr(ByVal Str) ; StrPtr(Str)
It is discussed at the first of the references below, but I cannot quite understand what they are on about. Apparently the StrPtr( ) was introduced to make sure you go to the actual Unicode UTF-16 LE encoding Bytes start bit. (the 5th byte along ). But VarPtr(ByVal Str) seems to be doing this. Is this maybe VBA being a bit cleverer with the VarPtr( ) than VB is / was?

Q10 This is similar to Q5. The 32 bit address value/ number of the variable Str (by me 2355700** ) , is itself somewhere in memory. I don’t know where, that is to say I do not know the memory location holding that number . I don't particularly care. I am just wanting that confirmed.
Is that correct?

I think the rest of the coding makes sense to me. The VBA Pointer address generally does not change, (code line 5), the other 2(3) code lines 6 and 7 all do the same thing ( differences in what / how is Q9c). Although the 3 values are always the same value, that value will likely change every time you run the coding. I am OK with understanding what is going on there

( As for code line 8, that, and related VB API stuff, is the subject of another Thread I want to get back to, but I got a bit stuck on the issues I raised in this Thread, so later on that one. - Just passing interest, a taste of interesting things to come as it were, …. what we have in code line 8 is VBA knowing what's going on. VBA does a lot of heavy stuff for us. APIs in VBA on the other hand, can get a bit confused, … the poor old things can even get confused with VB strings more than half the time…. But we will soon have all that sorted as well,

, :wink: :grin:

)

String example coding

Code:

Sub ConfusedWithVBAandVBStringPointerStuff() '  https://www.excelfox.com/forum/showthread.php/2404/page3#post11886
1 Dim Str As String
2 Debug.Print VarPtr(Str)        '  2355700   I don't know where this number is held in memory. I don't care
3 Debug.Print VarPtr(ByVal Str)              ' 0
4 Debug.Print StrPtr(ByVal Str); StrPtr(Str) ' 0   0

 Let Str = "ABCD"
5 Debug.Print VarPtr(Str)        '  2355700 - makes sense - no reason for this address to change. It is the first Byte of the 4 bytes that holds the VB pointer/ address, whatever value that is
6 Debug.Print VarPtr(ByVal Str)               '  4028444
7 Debug.Print StrPtr(ByVal Str); StrPtr(Str)  '  4028444  4028444

8 Debug.Print Str
End Sub

Q 11. Is the following beautiful sketch an accurate technical depiction of the situation just before the above coding ends?
In that sketch I have enclosed 3 memory chunks, and I have, sort of , connected them with arrow/pointers:
, starting form the bottom there are two memory chunks of 4 Bytes.
The bottom I know what is in it but not where it is.
The middle one I know where it is and what is in it
The top enclosed memory chunk in this example is 14 bytes, ( it would be 18 Bytes if I had ABCDEF, and so on ).

https://i.postimg.cc/L6zbgmFC/A-VBA-...y-any-name.jpg

Thanks for any help, comments , confirmations etc
Alan

Ref: VarPtr , StrPtr stuff
https://classicvb.net/tips/varptr/
https://www.vba-tutorial.de/referenz/zeiger.htm

**DocAElstein** · 02-09-2017, 05:10 PM

sdmbsmbf

**DocAElstein** · 02-09-2017, 05:10 PM

Buffer Post COFFee table ideas

This post reserved probably for Pallet stacking Ideas and Trendy COFFee tables made with norm dimensioned/size wooden Pallets

Arising from this

By definition a VBA Long is 32bits, So ... yes. But that's not why the memory location has not changed. I am not going to get into the Common Object File Format (COFF) and symbol tables here, but that provides you some nice new keywords to Google ... (but be warned, you are moving very much away from VBA here). This, by the way, is essentially the "... 'stack' of active variables and their values somewhere we ain't privy to?"

>_ the number the second code line, Debug.Print VarPtr(Lng) , gets me,
>_ is it the variable Lng

Lng is the symbol for the pointer,
VarPtr(Lng) gets you the value of the pointer, which is the memory address the pointer is pointing to
Lng itself is stored in the COFF symbol table

Note that one of the whole points of high-level languages is to (try to) hide this stuff away from you.

Snowy pisc, from this time of the year. - Impracticle conditions for Stacks of Coffee tables Ideas

Beutiful but difficult to do Palllet Stacking experiments.jpg
https://i.postimg.cc/90WBwmMH/Beutif...xperiments.jpg

Earlier Pics

Pooh Bahnhof im Bau.jpg Pooh BahnHof im Bau.jpg Stacking Ideas.jpg

Team work