I thought Chip's example was clear but I guess we all see things different
ways.

In my example use of ObjPtr was to demonstrate that all the references, the
original, the ByRef & ByVal all pointed to the same intrinsic object and
therefore no copy of the object was created. I posted this early in the
thread when you were disinclined to accept that was how it worked.

The example also showed, that as far as the intrinsic object is concerned,
there is no difference between using ByVal or ByRef. However there most
certainly is a difference in what may or may not happen to the object
variables depending on how they are passed.

I fully accept there are always better ways of explaining things, but that
does not mean either of the examples were not valid.


However, note, there is nothing in the documentations to make this point
dealing with *NON* intrinsic objects.

I don't follow "non". I used the term "intrinsic" to refer to the object
"thing", as distinct from an object variable which stores the address that
"points" to the block of memory where the object currently exists
(simplified).

Does that mean the other sources are incorrect?

I haven't read anything that is technically incorrect but I agree there is
not much in the way of explanation on this particular aspect.


I still don't follow your objective and problem. Why not post a simplified
example.

Regards,
Peter T


"Ronald Dodge" wrote in message
...
Maybe, but it was more so the method that he used that worked out the same
under both scenarios, so that didn't prove anything to me. What did prove
it to me was when I changed the code inside of the ByVal method to change
the property of the local object and then print all 3 object variable's
Text property to the immediate window while still in the method and after
changing the Text property of the local object variable.

However, note, there is nothing in the documentations to make this point
dealing with *NON* intrinsic objects.

Does that mean the other sources are incorrect?

Some of them are (primarily the ones in the help files, though they are so
vague anyhow, they don't do much good), while others not really so as they
mainly used simple data type variables to make their point, and then used
intrinsic objects to show that it doesn't work that way for those objects.
However, there's nothing stated anywhere that I saw dealing with custom
objects.

Maybe lesson learned by all 3 of us. For me, it was realizing that the
documentations were misleading or incorrect (which ever may have been the
case) while for the 2 of you, using a proper example that shows a clear
distinction without using something that could end up returning the same
result (In Chip's case) and don't use an example that has something in it
that has an unknown in it like what your example had with the ObjPtr
Function.


"Peter T" <peter_t@discussions wrote in message
...
You have misinterpreted Chip's example.

In the ByRef example the object variable C1 is in effect is re-assigned
to point to the C2 instance, at which moment the C1 class is destroyed as
the C1 pointer was the sole reference to the class object. That did not
occur with the ByVal example. Totally predictable and consistent with
what I have been trying to explain, without success.

Is there a reason you do not want to try the example I had posted, maybe
if you do things will become clearer.

Regards,
Peter T


"Ronald Dodge" wrote in message
...
Take a look at Chip Pearson's response, then my response right back
using his own code example and debug print out.

Yes, an object variable is a pointer to an object, but that is the only
way how a programmer can interact with an object. However, there is a
pretty big difference difference between ByRef and ByVal, and you seem
to be missing it, just like Chip also missed it.

If ByVal and ByRef both merely had a pointer to the original object, C1
in lines 2 and 4 would both be stating "222", not "111" in Line 2 and
"222" in Line 4. Study carefully the difference between Line # 2 and
Line # 4 in his example.


"Peter T" <peter_t@discussions wrote in message
...
There is nothing there that says anything about creating a replica
object for ByVal. The closest to what you have in mind is this -

When you pass arguments by value, Visual Basic makes a temporary copy
of the variable and passes the copy rather than the original. When
the procedure ends, Visual Basic throws the copy away--and changes are
discarded.

But you are missing the point. An object variable is a pointer to an
object. Sending an object ByVal makes a copy of the pointer as a new
object variable. Both original and new variables both point to the same
object. This bit - "and changes are discarded" as relates to an object
ByVal refers to any reassignment or destruction of the object variable,
but not to any changed properties of the actual object which will
persist.

I take it you didn't try the example I gave that demonstrates.

Regards,
Peter T


"Ronald R. Dodge, Jr." wrote in message
...
But that still doesn't answer the question to how to deal with the
original issue with *NON* intrinsic objects.


As to answer your question, even within the VBA help file under
"Statements", then any one of the items listed below:

Function Statement
Property Get Statement
Property Let Statement
Property Set Statement
Sub Statement

When you look up the ByVal, it states:

---START QUOTE---

Optional. Indicates that the argument is passed by value.

---END QUOTE---

If you click on the link of "by value", it further states:

---START QUOTE---

by value

A way of passing the value of an argument to a procedure instead of
passing the address. This allows the procedure to access a copy of
the variable. As a result, the variable's actual value can't be
changed by the procedure to which it is passed.

---END QUOTE---

Also as stated in other sources such as in Access 2002 VBA Handbook by
Susann Novalis and Dana Jones on page 367:

---START QUOTE---

When you send a copy of the variable's value, VBA creates a copy in
another temporary storage location in memory and sends the copy. The
called procedure can use the copy and may even change it's values, but
because the called procedure is working with a copy, the variable
itself is not affected. Sending a copy of the variable is called
passing the variable by value.

---END QUOTE---

While this is VBA with Excel, regardless if it's within Excel or
Access, it's still the same VBA language and structure, just with a
different set of objects and variables pertinent to the application.
Okay, here's one from "Using Excel Visual Basic For Applications,
Second Edition" by Jeff Webb on page 52:

---START QUOTE---

Besides data types, you can also specify how Visual Basic passes
arguments to a procedure. By default, Visual Basic passes a reference
to the argument. Any changes to the argument are reflected in the
variable that was passed in as the argument.

---END QUOTE---

This is stating that, using ByRef, or the omission of using either one
of the 2 key words, any changes done to the object is reflected both
inside and outside of the called procedure.

Now, go to page 53 of the same book, but only for the ByVal keyword:

---START QUOTE---

When you pass arguments by value, Visual Basic makes a temporary copy
of the variable and passes the copy rather than the original. When
the procedure ends, Visual Basic throws the copy away--and changes are
discarded.

---END QUOTE---

Though I'm dealing with passing arguments onto properties as opposed
to methods, it's the same deal. That very last one quoted pretty much
spelt it out.

You wanted my sources for my understanding of these 2 keywords, you
got them.


However, there's one exception to this rule, and you relied on this
one exception.

Variable/Object names that are global to the application, those names
can't be used for anything else, so when you attempt to use the ByVal
with such variables or variable types, they won't react the same way
as described in the help files. For that reason, these global
variables/objects are known as intrinsic to the application, which is
why they have a different behavior as compared to any other
variable/object that's not considered as global at the application
level.
--
Thanks,

Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Peter T" <peter_t@discussions wrote in message
...
Strange, I didn't see this when I followed up to your earlier
message. Anyway I trust the example in the follow-up clarifies.

Regards,
Peter T


"Ronald R. Dodge, Jr." wrote in message
...
As far as I can tell, what you are saying only works with intrinsic
objects.

Given my custom objects are within a project, not part of the
application itself, but the very definition of intrinsic objects, my
custom objects are NOT intrinsic objects, thus your argument for how
the ByVal works would not work out.

--
Thanks,

Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Peter T" <peter_t@discussions wrote in message
...
ByVal - Creates a whole new replica of the object with all of the
same settings as the object that is being passed onto it

No it doesn't. It creates a new (temporary) pointer to the original
intrinsic object.

As far as the original object's properties are concerned there is
no difference between using ByRef and ByVal.

Regards,
Peter T


"Ronald R. Dodge, Jr." wrote in message
...
The way I understood the ByRef and ByVal are the following:

ByRef - References to the object, and any changes done to the
object is done for any variable referencing to that object, rather
it be done in the original code or in the code referencing to the
object.

ByVal - Creates a whole new replica of the object with all of the
same settings as the object that is being passed onto it, but any
changes done to the original object is not reflects in the new
object, just like any changes done in the new object is not
reflected in the original object.

Though I haven't fully tested it to be sure with object variables,
but simple data type variables does work like this.

--
Thanks,

Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Peter T" <peter_t@discussions wrote in message
...
Afraid I don't follow most of that, maybe a simple example might
help.

One thing though, I think you are misunderstanding the difference
of passing an object byref & byval. Either way, any changes to
the object's properties will persist.

The only difference is with byval a new pointer to the original
object is created and passed. This means even if you destroy or
reassign the byval object within the procedure, the original
object variable will continue point to the same object.

Regards,
Peter T



"Ronald R. Dodge, Jr." wrote in message
...
Office XP, SP3 (VBA 6.0)
WIN XP, SP2


I have read over the text dealing with custom objects

According to the text that I have read online from MS
themselves, the keyword "NOTHING" should only destroy the object
when there is no other variable refering to that object.
However, as I have learned the hard way, that is not the case.
Any time any variable is set to NOTHING, the object is
destroyed, so any object variable referencing to that object is
then also set to NOTHING.

Example:

PayCode collection has a set of objects containing properties.
One of those PayCode objects is passed onto an Employee Object.
It's passed into the employee object via a property with the
object using the ByRef within the signature line, so if there's
any changes to the PayCode object, it's not only changed within
the PayCodes collection, but also within the Employee's PayCode
reference to it.

However, if the Employee Object is set to be destroyed, via the
clean up code, the code should be to set the object variable
within the Employee Object to NOTHING. However, doing that not
only does that, but also set's that particular object within the
PayCodes collection to NOTHING as if the object itself has been
destroyed.

How do I resolve this issue, so as I can have it reset only the
variable, not destroy the actual object, but yet, also allow for
changes to carry into the variable when they are done into the
main object?

--
Thanks,

Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000