Tricky VB/VBA side effects, and how to avoid them

[Steve Jorgensen]

== On Error Resume next, and Err.Number ==

If you want to call one of your procedures from another procedure, and check
for errors afterward, you mayimagine that you should write code something like
this...

On Error Resuse Next
MyFoo 123
lngErrNum = Err.Number
On Error Goto 0

.... so you do that, and it seems to work. A while later, you add code inside
MyFoo that does something similar, and now you find that the code above
sometimes detects an error when it shouldn't. This is because sometimes, the
error information never does get cleared after the error is skipped in the
called procedure, so it's still there when the calling procedure checks it.

I recommend engineering out this possibility at both ends. First, always do
an explicit Err.Clear after an "On Error Resuse Next" section, and second,
always trap for the occurrence of errors in calls to other procedures in the
same project using On Error Goto <label>, not On Error Resume Next, in spite
of the extra code involved.

== Passing object values to Variant parameters of procedures ==

Let's say you have a procedure that takes a Variant as a parameter, and adds
the parameter value to a collection. Now, let's say you call that procedure
from code in a form, and pass it, say, Me!txtName as an argument, then close
the form. Later, when you try to read the value back out of the collection,
you get an error. Why?

For convenience, VB allows certain objects to behave as values when you treat
them as values and as object references when you treat them as object
references, thus I can say either strName = Me!txtName to get the value from
the control, or Set ctlName = Me!txtName to make a reference to the control.

When you pass an object as a Variant parameter, there is nothing about the
syntax that tells VB whether to use the value or the object refence, and it
will always use the object reference in this case. This works fine only so
long as the procedure either expects an object, or does something internally
that causes the value interpretation of the object to be used while the
object's state is still valid.

This problem is really insidious since it can cause procedures to break after
a change that seems inconsequential , and can cause code to work some
circumetances, and not in others (e.g. work in testing, and fail when you demo
to the customer).

Again, I recommend solving the problem at both ends, just to cover all your
bases. When you want to pass the value of an object to a procedure, be
explicit about it, and pass something like Me!txtName.Valu e. When writing a
procedure that takes a variant and needs to deal only with a value, not an
object reference, convert any object reference you get to a plain value.

Sub Foo(varValue As Variant)
Dim varUseValue As Variant
varUseValue = varValue
...

== Passing object references ByVal vs ByRef ==

Given the issue above, you may think you can solve the problem by defining
your function parameters as ByVal. That should always get the value of the
object, not the object reference, right? Wrong.

There are actually 2 levels of metaphor going on here.

First, for parameters that are passed by "reference" , the function uses an
indirect reference back to the variable in the calling procedure, so the
entire item does not have to be copied (a good thing for a string or an
array), and so that any changes made to the "value" (more on this below)
affect the value of the variable passed to the procedure in the calling code
as well.

Second, there are object type variables that have "references " to object
instances stored in memory, but these are -not- the same thing ByRef means by
"references ".

It turns out that what it actually means to pass an object variable by
reference or by value is that if you pass it by reference, assigning the
parameter variable a reference to a new object instance affects the variable
in the calling procedure as well, so that it now also points to the new object
instance.

When passing by value, a separate, new reference to the same object instance
is created in the called procedure, so that changes made to the state of the
instance are still shared between the caller and called procedure (the 2
references are to the same instance), but assigning a new instance to the
parameter variable within the called procedure does not also affect the
variable in the calling procedure (the 2 references are now to different
instances).

== ByRef and side effects ==

Parameters in VB/VBA are ByRef if you don't specify, and that means that a
change made to the parameter in a called procedure affect the calling
procedure. No new news here. What that means, though, is that you really
have to be careful because it's common to use a parameter as a variable with
an initial state that can then be changed as part of the procedure's process.
if you don't remember to make the parameter ByVal, you just accidentally
mangled a value in the calling procedure, and this kind of bug can be really
tricky to track down.

I recommend yet another 2-pronged attack on this problem. First, always
specify ByVal for any parameter that has no specific, good reason to be ByRef
(and performance is only a good reason when you are having or expect to have
an actual performance problem). Second, never, ever assign a value to a
parameter variable unless it actually is for the purpose of returning a value
to the calling procedure through a ByRef parameter. In all other cases, use
local Dim'd variables for any values that can be changed during the execution
of the procedure.

[David W. Fenton]

Steve Jorgensen <no****@nospam. nospam> wrote in
news:7s******** *************** *********@4ax.c om:

Again, I recommend solving the problem at both ends, just to cover
all your bases. When you want to pass the value of an object to a
procedure, be explicit about it, and pass something like
Me!txtName.Valu e. When writing a procedure that takes a variant
and needs to deal only with a value, not an object reference,
convert any object reference you get to a plain value.

Sub Foo(varValue As Variant)
Dim varUseValue As Variant
varUseValue = varValue
...

Does putting () around an object cause the evaluated value to be
passed?

Wouldn't using ByVal fix the problem, too, assuming you don't want
to operate on the value itself (which you wouldn't really be able to
do with .Value, anyway)?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam. nospam> wrote in
news:7s******** *************** *********@4ax.c om:

== Passing object references ByVal vs ByRef ==

Given the issue above, you may think you can solve the problem by
defining your function parameters as ByVal. That should always
get the value of the object, not the object reference, right?
Wrong.

There are actually 2 levels of metaphor going on here.

First, for parameters that are passed by "reference" , the function
uses an indirect reference back to the variable in the calling
procedure, so the entire item does not have to be copied (a good
thing for a string or an array), and so that any changes made to
the "value" (more on this below) affect the value of the variable
passed to the procedure in the calling code as well.

Second, there are object type variables that have "references " to
object instances stored in memory, but these are -not- the same
thing ByRef means by "references ".

It turns out that what it actually means to pass an object
variable by reference or by value is that if you pass it by
reference, assigning the parameter variable a reference to a new
object instance affects the variable in the calling procedure as
well, so that it now also points to the new object instance.

When passing by value, a separate, new reference to the same
object instance is created in the called procedure, so that
changes made to the state of the instance are still shared between
the caller and called procedure (the 2 references are to the same
instance), but assigning a new instance to the parameter variable
within the called procedure does not also affect the variable in
the calling procedure (the 2 references are now to different
instances).

Steve, I don't understand this -- I can't quite get your point.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Wed, 01 Sep 2004 19:17:05 GMT, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote:

Steve Jorgensen <no****@nospam. nospam> wrote in
news:7s******* *************** **********@4ax. com:

Again, I recommend solving the problem at both ends, just to cover
all your bases. When you want to pass the value of an object to a
procedure, be explicit about it, and pass something like
Me!txtName.Valu e. When writing a procedure that takes a variant
and needs to deal only with a value, not an object reference,
convert any object reference you get to a plain value.

Sub Foo(varValue As Variant)
Dim varUseValue As Variant
varUseValue = varValue
...
Does putting () around an object cause the evaluated value to be
passed?

Yes, but that reads strangely when you are only passing one parameter. If
it's a Sub call, it looks like you put in parenthes that don't belong there,
and if you call a function, it looks liek you have an extra set. Either way,
you or someone else maintaining the code might end up taking them out later.
Wouldn't using ByVal fix the problem, too, assuming you don't want
to operate on the value itself (which you wouldn't really be able to
do with .Value, anyway)?

In another section of my post, I tried (not very well, apparently) to explain
why it turns out that it would not, though I've only understood this for a
short time, myself. When objects are involved, ByVal is misnamed, because it
doesn't force the object's value to be evaluated, it just makes a new
reference to the object instead of sharing the calling procedure's reference
to the object.

If that makes sense, then it answers the question in your other post as well.
Perhaps, an example would help, though.

Let's assume my form has controls txtValue1, containing "aaa" and txtValue2
containing "bbb". The following code doesn't resemble anything you would
actually do, but it illustrates the behavior I'm trying to explain.

First, here's the output from the code below...

txtValue1=aaa txtValue2=bbb
txtValue1=aaa txtValue2=xxx
ctl.Name=txtVal ue2
txtValue1=yyy txtValue2=zzz
ctl.Name=txtVal ue2

Now, the code...

Private Sub Foo()
Dim ctl As Access.Control

Debug.Print "txtValue1= " & Me!txtValue1, _
"txtValue2= " & Me!txtValue2

Set ctl = Me!txtValue1
Bar ctl
' Me!txtValue2 now contains "xxx"
' ctl now contains a reference to Me!txtValue2
Debug.Print "txtValue1= " & Me!txtValue1, _
"txtValue2= " & Me!txtValue2
Debug.Print "ctl.Name=" & ctl.Name

Set ctl = Me!txtValue2
Baz ctl
' Me!txtValue1 now contains "xxx"
' ctl still contains a reference to Me!txtValue2
Debug.Print "txtValue1= " & Me!txtValue1, _
"txtValue2= " & Me!txtValue2
Debug.Print "ctl.Name=" & ctl.Name

End Sub

Private Sub Bar(varValue As Variant)
' Because parameter is by reference, the next line changes
' what control the calling code's parameter variable points
' to as well.
Set varValue = Me!txtValue2
varValue.Value = "xxx"
End Sub

Private Sub Baz(ByVal varValue As Variant)
' ByVal gave us a separate, local reference to the object,
' but it's still an object reference, not a value.
varValue.Value = "zzz"
' Because parameter is by ByVal, the next line only affects
' the state of the local varValue.
Set varValue = Me!txtValue1
varValue.Value = "yyy"
End Sub

[david epsom dot com dot au]

> Does putting () around an object cause the evaluated value to be

passed?

Wouldn't using ByVal fix the problem, too, assuming you don't want
You do get tricky VB/VBA side effects :~)

For example, this does not just pass a string value:

call sb((codedb.name ))

private sub sb(byval s as string)

.... for some reason it actually does retain a
reference to the temporary db object, which you
can see inside sub sb if you iterate through
the databases collection.

This has a quite different effect:
s = codedb.name
call sb(s)

(david)

"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@24. 168.128.74... Steve Jorgensen <no****@nospam. nospam> wrote in
news:7s******** *************** *********@4ax.c om:

Again, I recommend solving the problem at both ends, just to cover
all your bases. When you want to pass the value of an object to a
procedure, be explicit about it, and pass something like
Me!txtName.Valu e. When writing a procedure that takes a variant
and needs to deal only with a value, not an object reference,
convert any object reference you get to a plain value.

Sub Foo(varValue As Variant)
Dim varUseValue As Variant
varUseValue = varValue
...

Does putting () around an object cause the evaluated value to be
passed?

Wouldn't using ByVal fix the problem, too, assuming you don't want
to operate on the value itself (which you wouldn't really be able to
do with .Value, anyway)?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Thu, 2 Sep 2004 12:24:17 +1000, "david epsom dot com dot au"
<david@epsomdot comdotau> wrote:

Does putting () around an object cause the evaluated value to be
passed?

Wouldn't using ByVal fix the problem, too, assuming you don't want

You do get tricky VB/VBA side effects :~)

For example, this does not just pass a string value:

call sb((codedb.name ))

private sub sb(byval s as string)

... for some reason it actually does retain a
reference to the temporary db object, which you
can see inside sub sb if you iterate through
the databases collection.

This has a quite different effect:
s = codedb.name
call sb(s)

(david)

To me, that is less of a side effect than what I'm talking about. When a
dynamic object reference is created within a statement, the reference is
always held until the statement completes. This is actually to prevent side
effects such as what would happen if you tried to pass a tabledef to a
procedure using Foo CurrentDb.Table Defs("tblBar"). If the dynamic reference
to the database instance returned by CurrentDb were allowed to go out of scope
immediately, then Foo would not be able to use the TableDef reference that was
passed to it. You can think of the behavior as being similar to a With block.

[rkc]

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:cj******** *************** *********@4ax.c om...

In another section of my post, I tried (not very well, apparently) to explain why it turns out that it would not, though I've only understood this for a
short time, myself. When objects are involved, ByVal is misnamed, because it doesn't force the object's value to be evaluated, it just makes a new
reference to the object instead of sharing the calling procedure's reference to the object.

What would an object's value be evaluated to? Objects created with
VBA have no way to set a defaut value.

[Steve Jorgensen]

On Thu, 02 Sep 2004 03:22:39 GMT, "rkc" <rk*@yabba.dabb a.do.rochester. rr.bomb>
wrote:

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:cj******* *************** **********@4ax. com...

In another section of my post, I tried (not very well, apparently) to

explain

why it turns out that it would not, though I've only understood this for a
short time, myself. When objects are involved, ByVal is misnamed, because

it

doesn't force the object's value to be evaluated, it just makes a new
reference to the object instead of sharing the calling procedure's

reference

to the object.

What would an object's value be evaluated to? Objects created with
VBA have no way to set a defaut value.

Of course, this whole discussion can only refer to cases where you're passing
around references to objects that do have default value properties. While you
can't (without cheating) create these yourself in VBA, there are many cases
where we use and pass sround existing objects that do have default value
properties, such as fields and controls. It is when we pass these as
arguments to functions that the issues arise.

[Steve Jorgensen]

On Thu, 02 Sep 2004 09:22:50 GMT, Chuck Grimsby
<c.*******@worl dnet.att.net.in valid> wrote:

On Wed, 01 Sep 2004 10:26:36 GMT, Steve Jorgensen
<no****@nospam .nospam> wrote:

== On Error Resume next, and Err.Number ==

<snip>

Sub Foo(varValue As Variant)
Dim varUseValue As Variant
varUseValue = varValue
...

When doing this, use a function, not a sub, and return back the error
number so that the calling function can react to the error.

I'm not sure why that's better.
1. The onus on the error trapping has now simply moved from the calling code
into the called code.
2. Perhaps the procedure to be called is already, logically a function, not a
sub, that returns something else besides an error number as its value. In
other words, we already have a communication channel for error information,
why use up another communication channel that we might want for something
else?
3. What if not every caller expects to repond directly to an error? Perhaps,
the error handling is better done farther up the call stack.

[Steve Jorgensen]

On Thu, 02 Sep 2004 22:51:46 GMT, Chuck Grimsby
<c.*******@worl dnet.att.net.in valid> wrote:

On Thu, 02 Sep 2004 20:27:50 GMT, Steve Jorgensen
<no****@nospam .nospam> wrote:

On Thu, 02 Sep 2004 09:22:50 GMT, Chuck Grimsby
<c.*******@wo rldnet.att.net. invalid> wrote:

On Wed, 01 Sep 2004 10:26:36 GMT, Steve Jorgensen
<no****@nosp am.nospam> wrote:

== On Error Resume next, and Err.Number ==
<snip>
Sub Foo(varValue As Variant)
Dim varUseValue As Variant
varUseValue = varValue
...When doing this, use a function, not a sub, and return back the error
number so that the calling function can react to the error.

I'm not sure why that's better.
1. The onus on the error trapping has now simply moved from the calling code
into the called code.
2. Perhaps the procedure to be called is already, logically a function, not a
sub, that returns something else besides an error number as its value. In
other words, we already have a communication channel for error information,
why use up another communication channel that we might want for something
else?
3. What if not every caller expects to repond directly to an error? Perhaps,
the error handling is better done farther up the call stack.

When you have the error number, the calling code can react in a
"custom" method rather then a general. As you well know, all sorts of
bizarre things can happen to objects as they are passed around and
manipulated by various subs and functions. Especially if the code
called is doing it's own error handling that the calling code will
never know about.

I'm not sure I get what you're getting at. The calling code can respond the
the error in a custom way by trapping the error as well, without needidg the
return value. Admittedly, that takes more code in the calling procedure, but
you're now putting the onus on the called procedure to know that the calling
procedure will want to know the error code, and will want to know it
disticntly for that call and not generically for a series of statements (say,
3 calls within a loop).

Further more, you must either...
A) assume every caller will want error information returned as a parameter,
and always do that, then have to return any other data via reference
parameters which often increases the mumber of lines of code requireds in the
calling procedure
B) modify each procedure when you find out that a calling procedure will want
to handle error information distinctly for that procedure. In this case, you
may break other code that was trapping for errors, and expecting an error
branch if one did occur.

Also, if the called procedure is trapping its own error, how likely is it that
the calling procedure will actually need to know which error it was. Perhaps,
a mere boolean success/failure code would be a more appropriate thing to
return.

I think it's more consistent to try to use the exception handling mechanisms
for error trapping, and use function return values to return processing output
from function procedures.

Here's some thinking out-loud about a sort of compromise between our 2
positions...

Add an optional ByRef Variant parameter to the called procedure that can be
used to retrieve its exception information. Have the called procedure's error
handler re-raise the exception if the variant parameter IsMissing(...), or
pass the error info back to the calling procedure via the parameter if it is
not missing.

Now, the calling procedure can either use error trapping or not as desired,
and it can avoid error trapping without the use of On Error Resume Next simply
by passing an argument to collect the error information. This can be used
even with a function procedure that has reason to return something other than
error information as its return value. One potential source of trouble here
is that the error info parameter must be initialized, and that's easy to
forget. I guess that's an advantage to the return value as opposed to the
ByRef argument.