"Terry Kreft" <terry.kreft@mps.co.ukwrote in
news:DdudnY28zslSBanYRVnyjg@eclipse.net.uk:
Quote:
It was a stupid decision because if the Container property had
been implemented as a pointer back to the document container
object it would have made navigation through the collection much
more fluid, and utilising a Name property on this theoretical
object would have achieved the same purpose as is currently
offered by the Container property.
I've rethought this whole issue, and decided that I may agree to
you.
In the model you are proposing you could do this:
MyForm.Container
and get a reference to the parent container.
But that reference doesn't mean anything anywhere in Access. It
would only be useful if you could refer to something by name when
you didn't know what the type of that thing was. I can't think of
any context where we can utilize an Access object (not a Jet object)
interchangeable without needing to know its parent container.
Likewise, the subroutine posted by MLH took a Document object as its
sole parameter. There is actually no way in Access to do a:
Dim doc As Document
Set doc = [something that returns a document-type ref]
without doing it off of a container object. This is because there
are no functions or properties anywhere in Access that return a
reference of type Document except the children of containers.
Put another way, you can't get to a document without going through
the parent container. This means you have to know the parent
container to get to the document in the first place, so you already
know the name of the parent container in any context in which you
could even attempt to evaluate the value of doc.Container or of the
hypothetical doc.Container.Name.
Now, I don't know how you could unify these namespaces in Access so
that you could just refer to something by name without a container
identified, but it seems that you are claiming that doing it that
way is somehow both inconsistent with the rest of Access and
undesirable. While I might agree that it's undesirable, it is, in
fact, completely consistent with the rest of Access. Even in A2K and
above where you have CurrentProject.AllForms, etc., you still have
to go through the parent container, it's just a shortcut for
CurrentDB.Containers!Forms. It's certainly easier to understand and
a nice feature, but it doesn't actually fix the problem you seem to
me to be raising.
Indeed, it apparently returns a reference of type AccessObject,
instead of one specific to the collection/container, and it's only
the .Type property that tells you what type of object it is.
But, here again, you already know what type of object it is, because
the only way to get the reference is through a parent container.
Indeed, the model there seems rather incoherent, as it has a .Parent
property, which doesn't exist in any object that can be accessed
through one of the AllXXXX collections.
But all of that is irrelevant, as MLH is programming in A97, which
lacks those new collections.
It just seems to me that it's not at all inconsistent with the way
all of Access works, and that the property itself, whether it
returns an object pointer or a string, is pretty much irrelevant,
since you can't use the property in any context that is not already
being accessed through the relevant container/collection.
--
David W. Fenton
http://www.dfenton.com/
usenet at dfenton dot com
http://www.dfenton.com/DFA/ 
