Re: Nothing Keyword Destories Objects rather than just resetting the variable to an empty variable

Tech-Archive recommends: Fix windows errors by optimizing your registry

In case I wasn't fully clear on what's undesired, I want any aspect of the
object change to be reflected (thus why the ByRef), but I don't want any
other object variable pointing to the same object as the one object variable
is prior to it being redirected, for those other to be redirected (hence the
undesired effect of the ByRef).

Such as in Chips example.

When C was redirected, I didn't want C1 to also be redirected, but that is
what takes place when using the ByRef keyword.

"Ronald Dodge" <dodgester@xxxxxxxxxxxxxx> wrote in message
news:u%23uYdpLXJHA.4596@xxxxxxxxxxxxxxxxxxxxxxx
First off, in your example, what is the below doing to the object
variable, if anything:

objPtr(<argument1>)

This is too incomplete as there could be different things taking place.


Okay, in Chip's example, let's look at the ByVal route first.

The moment it was passed to C in the "PassByVal" sub, a replica was
created. The object pointed to C1 is still retained by the reference to
C1. Therefore, you now have 3 different objects created within VBA.

When C was set to C2 within the "PassByVal" sub, the object variable of C
pointed to the same object as the Object Variable of C2. However, the
object variable of C1 did not point to the same object, that the object
variable of C2 pointed to. At this same point of time, the replica that
was created via the ByVal keyword is now destroyed, so now you have C
(local variable) and C2 (module variable) both pointing to the same object
while C1 (module variable) is pointed to the original instance it was
created to point to. Now, you are back to 2 different objects, which are
the original 2 created in the procedure that called on the sub procedure.

Now, when the sub procedure ended, the object variable of C was also set
to NOTHING as it went out of scope.

Hence, when C1.Text was printed, it still printed "111" while C2.text was
printed as "222".


Now, C1.Text and C2.Text was put to "111" and "222" respectively.

Next line, but only passing to the sub procedure of "PassByRef"

Now, C1 is passed into the "PassByRef" subprocedure, but onlly as "ByRef",
thus the local object variable of C in "PassByRef" is referencing to the
exact same object as the module level object variable of C1. At this
point, you still have 2 objects within VBA and didn't create a third
object like you had in the "PassByVal" subprocedure.

Now, let's move onto the Set line within the sub procedure of "PassByRef"

At this point, the local object variable of C is set to point to the same
object as the module level object variable of C2 points to.
However, cause of the local object variable of C was reference to the same
object as the module level of C1 was referencing to, the object variable
of C1 was also pointed to the same object as the object variable of C2.
Therefore, as a result, the object that the object variable of C1 was
originally pointed to has been destroyed.

The problem I have with the PassByVal method, it replicates the object,
which I don't want that.

The problem I have with the PassByRef method, it not only redirects the
local variable (Desired), but also redirect the original object variable
that was passed onto the sub procedure to the object of what it has been
directed to point to indirectly via the local object variable (Undesired).



"Peter T" <peter_t@discussions> wrote in message
news:ORmY2LLXJHA.1532@xxxxxxxxxxxxxxxxxxxxxxx
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" <dodgester@xxxxxxxxxxxxxx> wrote in message
news:O0jNztKXJHA.868@xxxxxxxxxxxxxxxxxxxxxxx
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
news:%23D0rQYKXJHA.1184@xxxxxxxxxxxxxxxxxxxxxxx
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." <ronald.dodge@xxxxxxxxxx> wrote in message
news:unYk60JXJHA.5476@xxxxxxxxxxxxxxxxxxxxxxx
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
news:%23tWgmOJXJHA.4284@xxxxxxxxxxxxxxxxxxxxxxx
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." <ronald.dodge@xxxxxxxxxx> wrote in message
news:%23fgh5oIXJHA.1532@xxxxxxxxxxxxxxxxxxxxxxx
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
news:eMu%23VyHXJHA.5084@xxxxxxxxxxxxxxxxxxxxxxx
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." <ronald.dodge@xxxxxxxxxx> wrote in message
news:uh$8qoHXJHA.2440@xxxxxxxxxxxxxxxxxxxxxxx
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
news:%23hW%23JeHXJHA.4168@xxxxxxxxxxxxxxxxxxxxxxx
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." <ronald.dodge@xxxxxxxxxx> wrote in message
news:ecfkkFHXJHA.4852@xxxxxxxxxxxxxxxxxxxxxxx
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























.

Relevant Pages

  • Re: Nothing Keyword Destories Objects rather than just resetting the variable to an empty variable
    ... The object pointed to C1 is still retained by the reference to C1. ... C1 pointer was the sole reference to the class object. ... Though I haven't fully tested it to be sure with object variables, ... the keyword "NOTHING" should only destroy the object when there ...
    (microsoft.public.excel.programming)
  • Re: Different between ???.close and Set ??? = Nothing
    ... "Jamie Collins" wrote in message ... explicitly set object variables to Nothing when you're done with them, ... > always use ByRef, ... More important than either policy, though, is to have a policy and be ...
    (microsoft.public.access.modulesdaovba)
  • Re: Different between ???.close and Set ??? = Nothing
    ... > habitually doing so for all object variables makes it less likely that ... code harder to maintain e.g. for the developer who inherits your code. ... The original author probably knew which arguments *need* to be ByRef ... developer who used implicit Variant data type for all variables... ...
    (microsoft.public.access.modulesdaovba)
  • Re: Using ref
    ... "reference" for both object references and byref arguments ... It means pointer in both cases. ... Object variables are ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Nothing Keyword Destories Objects rather than just resetting the variable to an empty variable
    ... there is no difference between using ByVal or ByRef. ... as the C1 pointer was the sole reference to the class object. ... Yes, an object variable is a pointer to an object, but that is the only ... the keyword "NOTHING" should only destroy the ...
    (microsoft.public.excel.programming)