Yes for the first question. You declare a variable as public inside a form
(whatever this variable data type is an integer or a 'class'), then that
variable lives as long as the form itself lives.
If you declare, from a second source, a reference to the public variable
(property) from form FormA and then close the form FormA, then form FormA
will still live! Indeed, with COM, its reference count will not be zero
and a COM object releases its resources when its reference count is zero.
You may even have lost the 'graphical' part of FormA, but that does not mean
FormA is totally released, from memory.
Not what you ask, but may be of some interest:
If you make a real copy of (rather than keeping a reference to) the
variable, in that case, you end up with TWO clones, not TWO references to a,
one, single object, and then, closing FormA would kill one of the clone.
That being said, VBA has no pre-made syntax to make a copy rather than
making a reference, and if you really want a copy (clone) you are probably
due to use more or less complex sequence of win32 API calls. Consider that
your object can itself refer to other objects, in its variable declaration,
so, in theory, you may have to copy many objects, to effectively do what is
looking just like a single 'copy' of a single object. And while you may
think you just have to copy the children objects, think again, since the
'parent' may be referenced by a child and in this case, you do not want to
copy again the parent ( that will be a "make a copy" infinite loop). So,
indeed, copying an object is (or can be) a complex problem. That is why
using references, rather than copies, is the norm.
Vanderghast, Access MVP
