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