BYREF vs. BYVAL

the_net_2.0

Banned
Local time
Today, 12:12
Joined
Sep 6, 2010
Messages
812
I need a small refresher on this, guys. Is the difference very simple, or are there multiple components to this? Thanks.
 
an argument/parameter passed to a sub/function as follows

byval - a copy of the variable is placed on the stack, and (effectively) the address of that copy is passed to the sub. therefore any changes to the variable whether intentional or accidental are effected on the temporary copy, and are discarded when the subproc ends, and control returns to the calling statement

byref - the address of the actual variable is passed, rather than the address of a copy. So changes to the variable are permanent.

since in general, it is better to limit the scope of variables as much as possible, it is much safer to pass variables byval, and only explicitly byref when specifically required - therefore it is also surprising that the default setting in VBA is byref, rather than byval.
 
therefore it is also surprising that the default setting in VBA is byref, rather than byval.

Why are you surprised? That sounds like MS thinking to me. "do as much as possible for the person so they don't have to think". Is that what their motto is? :)

The reason I ask is because, today I ran across a situation where a recordset was opened in a proc, was passed to a subproc BYVAL, and was then edited in the subproc (records updated). I opened the db file after the code finished and the table was actually updated by the code.

Is that supposed to be right, Gemma?
 
The reason I ask is because, today I ran across a situation where a recordset was opened in a proc, was passed to a subproc BYVAL, and was then edited in the subproc (records updated). I opened the db file after the code finished and the table was actually updated by the code.

It is important to realise that when an object (such as a recordset) is passed as an argument, the values of its members can still be changed regardless of the ByVal or ByRef declaration.

Chip Pearson covers the subject quite well on this page.

However some clarification is required where he says that objects are always passed ByRef regardless of the declaration.

While this is true for objects themselves when passed as an argument, it is not the case for object variables. The difference is important.

As I said earlier, regardless of the declaration, the members of an object argument can be changed even if the call is ByVal. However a ByRef declaration also allows an object variable passed as an argument to be reassigned to a different object inside the procedure/function while this is not possible ByVal.

The bottom of the page shows how to force a call to ByVal even when the procedure is declared ByRef.

BTW Arrays cannot be passed ByVal.
 
Last edited:
thanks, sir. I love Chip Pearson's site. He's a very knowledgeable professional.

By the way, are you going to answer me back on the signed vs. unsigned thread? I'm kinda waiting for your feedback. :)
 
It is much safer to pass variables byval, and only explicitly byref when specifically required - therefore it is also surprising that the default setting in VBA is byref, rather than byval.

I expect it came from the days where memory was in short supply so a ByRef was more frugal.

It is a good habit to always declare, especially since the default in .NET is ByVal.
 

Users who are viewing this thread

Back
Top Bottom