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

[Ronald R. Dodge, Jr.]

Maybe it's unclear as to what intrinsic means within the programming world,
but from what I had gathered, any object or other value tied to the
application or some other referenced library (early or late binding, though
normally see it more readily with early binding), those are the items that's
intrinsic and therefore can't really be changed.

Yes, I am very critical as I have learned early on not to assume anything
unless I have no realistic choice. That is cause when one start going on
assuming things, they are taking on a much greater risk of getting
inaccurate results, which then can either get them into a lot of problems or
can make it rather tough to resolve. Some people may hate me for that fact,
but it's one of those day to day rules that has kept me out of trouble.
Therefore, without knowing what the ObjPtr did or seeing the code for it
(Not to mention someone could have made up their own UDF with that name,
though wouldn't think you would purposely do that, but nonetheless, there's
that assumption thing again), I couldn't really trust your example. That is
why I have rules like prequalify variables, don't rely on active objects,
use a proper naming convention, and use explicit coding only, as just a few
examples, unless of course, there is no realistic choice to break one of
those rules. That should be very rare to have such an exception and if it
does happen, it better be for a very good reason.

The only thing is, there must be a starting point, and documentations was
basically my starting point. If I attempted to prove every little thing
before using them, I wouldn't be nearly as far along as I am with my
programs. Yes, there has been times when documentations has proven to be
either incorrect or misleading, such as in this example, at the minimal,
very much so misleading. Another example, Excel specification states the
only limit to defined names is the amount of ram when in fact it's limited
to 65,536 defined names within a single workbook due to the fact the names
collection seems to have a 2 byte field for the index. Not only that, but
even after exceeding 32,768 defined names within a single workbook, the
workbook may become unstable. If a single workbook has in it more than
65,536 defined names in it at the time it's saved then closed out, the next
time it opens up, it goes into repair mode and the only items left in it are
the text/formula entries into the cells and maybe a few other minor stuff.
Pretty much everything else is gone like formats, charts, other worksheet
settings, and what not.

--
Thanks,

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

 

[Peter T]

Therefore, without knowing what the ObjPtr did or seeing the code for it

(Not to mention someone could have made up their own UDF with that name,
though wouldn't think you would purposely do that, but nonetheless,
there's that assumption thing again), I couldn't really trust your
example.

You mean using something like telepathy I might have planted a function in
your system, not a UDF but embedded into VBA.

A simple search would have found it, and probably the API alternative too
which you might have preferred over the non-officially supported vb
function.

Instead, because you didn't happen to know about ObjPtr, you concluded
anything (my explanations) based on its results should be disregarded
without further verification.

Healthy scepticism is fine but ..... [Sigh]
Peter T

 

[Ronald R. Dodge, Jr.]

Normally I tend to rely heavily on documentations, but when something is not
working as expected, that's when nearly all trust pretty much goes out the
window until the issue is found and the reasoning for the issue is found.
It's only then that further documentation should be noted and either added
to the current documentation or modify the current documentation to reflect
the real essence, so as to prevent further confusion to the extent
reasonably possible.

Yes, I know I'm bull headed when it comes to something like this, but I
don't care for chasing after something blindly under pretense assumptions
either. I don't plan on changing that any time down the road either. I
even did some searching over the web (how I resolve a good bunch of my
issues when documentations within the application fails, though some things
can only be found by experimentations as I apparently tend to push things
much further than pretty much most anyone else including the vendors
themselves). It's like that one movie (don't remember the name of it) where
the tax agent has caused another person to be arrested initially for
supposed tax evasion. That person then lost his son in a bad storm outside.
A few days later after that incident and with no luck of having his son
found, he then got into a car wreck that killed him. God gave him a second
chance, but only after criticizing him for what he did and didn't do, and
sent him back in time again. This time around, he was more or less
instructed to check out the guy's claim and it turned out to be true. This
time around, he didn't arrest the guy. His son still came up missing in the
bad storm, but this time cause he didn't arrest the guy, that guy was able
to use dogs to find his son, which his son was found within a few hours. As
he thanked that guy later, that guy also stated to him that he was tough,
but fair (note, this was at the point of time when it was done the second
time around, not the first time around).

Moral of this story, while one may have to be tough and critical (which I
know I was here with this case given the redirection issue of Chip's example
and the function issue with your example), it was at the minimal my duty to
point out what and why, so as we could address those issues and still being
fair about it. Therefore, I hope this explains as to why I was very
critical on the case. While you 2 were seeing it from each of your
different angles, I also saw it from an entirely different angle that you 2
probably didn't think about.

I know about being open minded, but at the same time, I also have to be
within boundaries, and I'm sure you 2 thought I was being too tough and not
open minded enough. However, when we attempt to figure out what other
angles that another person is coming from, we can really learn some things
from each other. It was when I took another look at Chips example as I was
in the process of criticizing it, while I still criticized the redirection
aspect, I was able to modify that particular part of the code to be able to
prove to myself if what I was saying was correct or if it was what you 2
were saying was correct, and I took that opportunity to once end this
dispute. Using the redirection (Set keyword in this case) in the case did
nothing to prove the issue as both scenarios would have had the same result,
but changing the properties and comparing them while still in the
subprocedure did prove it. One of the things about problem solving, you
often times have to look for differences to resolve those issues, just like
there are times when you have to look for similarities at times.

Some people have even accused me of asking too many questions on various
things, but it's again under this no assumption rule that I use unless it's
my only reasonable choice with keeping in mind of the risks involved.

At this point of time, I will review the codes and put in the proper clean
up codes so as even when the object variables are out of scope, the objects
themselves don't get left in memory inadvertently as I would hate to have
memory leak issues.

--
Thanks,

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

Therefore, without knowing what the ObjPtr did or seeing the code for it
(Not to mention someone could have made up their own UDF with that name,
though wouldn't think you would purposely do that, but nonetheless,
there's that assumption thing again), I couldn't really trust your
example.

You mean using something like telepathy I might have planted a function in
your system, not a UDF but embedded into VBA.

A simple search would have found it, and probably the API alternative too
which you might have preferred over the non-officially supported vb
function.

Instead, because you didn't happen to know about ObjPtr, you concluded
anything (my explanations) based on its results should be disregarded
without further verification.

Healthy scepticism is fine but ..... [Sigh]
Peter T

Maybe it's unclear as to what intrinsic means within the programming
world, but from what I had gathered, any object or other value tied to
the
application or some other referenced library (early or late binding,
though normally see it more readily with early binding), those are the
items that's intrinsic and therefore can't really be changed.

Yes, I am very critical as I have learned early on not to assume anything
unless I have no realistic choice. That is cause when one start going on
assuming things, they are taking on a much greater risk of getting
inaccurate results, which then can either get them into a lot of problems
or can make it rather tough to resolve. Some people may hate me for that
fact, but it's one of those day to day rules that has kept me out of
trouble. Therefore, without knowing what the ObjPtr did or seeing the
code
for it (Not to mention someone could have made up their own UDF with that
name, though wouldn't think you would purposely do that, but nonetheless,
there's that assumption thing again), I couldn't really trust your
example. That is why I have rules like prequalify variables, don't rely
on active objects, use a proper naming convention, and use explicit
coding
only, as just a few examples, unless of course, there is no realistic
choice to break one of those rules. That should be very rare to have
such
an exception and if it does happen, it better be for a very good reason.

The only thing is, there must be a starting point, and documentations was
basically my starting point. If I attempted to prove every little thing
before using them, I wouldn't be nearly as far along as I am with my
programs. Yes, there has been times when documentations has proven to be
either incorrect or misleading, such as in this example, at the minimal,
very much so misleading. Another example, Excel specification states the
only limit to defined names is the amount of ram when in fact it's
limited
to 65,536 defined names within a single workbook due to the fact the
names
collection seems to have a 2 byte field for the index. Not only that,
but
even after exceeding 32,768 defined names within a single workbook, the
workbook may become unstable. If a single workbook has in it more than
65,536 defined names in it at the time it's saved then closed out, the
next time it opens up, it goes into repair mode and the only items left
in
it are the text/formula entries into the cells and maybe a few other
minor
stuff. Pretty much everything else is gone like formats, charts, other
worksheet settings, and what not.

--
Thanks,

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