"Anja" <an*******@googlemail.comwrote in
news:11*********************@m7g2000cwm.googlegrou ps.com:
However, I fail to see the logic behind this thing... t is
designed in a pretty insane way!
It's an example of object orientation and instantiation of an
instance of a class.
A form is a wrapper around a class module.
Class modules can have instantiations that are independent of the
class definition.
For instance, you could have:
Dim cls1 As New clMyClass
Dim cls2 As New clMyClass
In that case you have two instances of the same class. Each instnace
will have independent properties, even though it is derived from the
same class definition.
In the case of a subform, you have an instantiation of the subform
class as a child object of the main form, and it only exists as a
child object of the main parent form.
Technically, it's actually a child object of a subform control on
the main form.
Thus, the instance of the form that you are working with is:
Form!ParentForm!SubformControl.Form
When you're working in the class module of the parent form, you can
refer to it thus:
Me!SubformControl.Form
One thing that confuses many people is that when you drop a subform
on a main form, the name of the subform control is identical to the
name of the subform itself. While this can be helpful, it is also
confusing, because you've got two completely different things using
exactly the same name, which tends to make it confusing to
distinguish the two.
I never let my subform controls have the same name as the subform
embedded in them. If the subform is called subMySubForm, I will name
the subform control MySubForm.
There is nothing inconsistent about the naming conventions here or
about the way you refer to data and properties of a subform. It is
completely consistent with the whole structure of Access, which is
based on subclassing and instantiation of various objects.
--
David W. Fenton
http://www.dfenton.com/
usenet at dfenton dot com
http://www.dfenton.com/DFA/ 
