On May 30, 2:21 pm, "news.microsoft.com" <rica...@microsoft.com>
[quoted text, click to view]

Hi,

What is wrong with what you suggested? :)

Moty

In some classes i have properties defined on others classes.

In the classes referenced by properties, i need a reference to "parent"
object.

Something like this

Public Class MainClass
Public property1 as ClsData
...
End Class

Public Class ClsData
private _parent as MainClass

Public readonly property Parent() as MainClass
Parent = _parent
End Property

Public Sub New(byval parentObject as MainClass, ...)
_parent = parentObject
...
End Sub
End Class

Can i use reflection (or anythingelse) to do this?

Thanks.

See the "Me" keyword i.e. somewhere in MainClass you'll have :

MyChild=New ClsData(Me)

--
Patrice

"news.microsoft.com" <ricardo@microsoft.com> a écrit dans le message de
news: %23iTisyqoHHA.1476@TK2MSFTNGP03.phx.gbl...
[quoted text, click to view]

On Thu, 31 May 2007 05:36:41 -0700, news.microsoft.com =

[quoted text, click to view]
=

[quoted text, click to view]

Without knowing your exact design, it's hard to say. But the first thin=
g =

that comes to mind is that it seems to me what you really need are some =
=

helper functions. For example, rather than writing out the explicit =

parent chain, have a loop that walks up the ownership chain until it fin=
ds =

the class it's looking for (in your example, the one with the Dataset =

property):

BaseObject objCur =3D this;

while (objCur !=3D null && !(objCur is DatasetContainingClass))
{
objCur =3D objCur.Parent;
}

if (objCur !=3D null)
{
// do something with ((DatasetContainingClass)objCur).Dataset
}

This requires that all of your objects inherit from a base object that h=
as =

a Parent property, of course, or at least some mechanism for returning i=
ts =

parent.

Alternatively, each class could have a Dataset property that defers to i=
ts =

parent's Dataset property if it does not itself have a Dataset property:=


class Child
{
private Parent _parent;

public DatasetClass Dataset
{
return _parent.Dataset;
}
}

Note that I am taking as granted that your child/parent relationship =

design makes sense. Again, without knowing the actual design, it's hard=
=

to say that's true for sure. Looking at the rest of your post, this isn=
't =

at all apparent:

[quoted text, click to view]

I don't think anyone mentioned inheritance as a solution, and for good =

reason: inheritance and a child/parent relationship are completely =

different. You wouldn't use one for the other. Conversely, if =

inheritance is a way to represent the relationships between your classes=
, =

then it may be that the child/parent relationship is the *wrong* way to =
do =

it, which could explain why you have such an unwieldy design in the firs=
t =

place.

Something to consider, IMHO.

[quoted text, click to view]

Reflection can get you the base class which a derived class inherits. I=
=

don't personally feel that the concepts of "nesting" or "child/parent" =

apply in this case (see above regarding how inheritance and parent/child=
=

relationships are completely unrelated). Regardless, reflection isn't =

going to get you anything here that a properly designed collection of =

classes won't. If you are, for example, considering using reflection to=
=

get at the various "parent" accessors for each class, it makes more sens=
e =

to define your class hierarchy so that anything with a "parent" inherits=
=

from a class that has a "parent" accessor. Then you can do the =

parent-searching code without needing reflection.

[quoted text, click to view]
=

[quoted text, click to view]

The "parent/child" relationship you're talking about (well, at least wha=
t =

you *appear* to be talking about) is defined in your own implementation =
of =

the classes. There's not really anything about the references that make=
=

them parent/child-specific, except how you interpret them. So reflectio=
n =

isn't going to automatically solve any sort of aspect of interpreting th=
e =

references (how, for example, would the reflection code know that one =

reference in a class is that instance's parent, but that another referen=
ce =

is not?).

I just don't see where reflection comes into it.

There's nothing wrong. But my set of classes it's a bit big. The chain
of objects that contains others objects can be deep and produces lines like
this
Me.Parent.Parent.Parent.Parent.Parent.Parent.Dataset

, and i must repeat the previous skeleton in every class. The code to do
this in all of the classes it's so great that i'm looking for an
alternative. Inheritance it's not an option because i'm already using
inheritance. I can use interfaces but it not avoid to write the necessary
code.

.NET languages are very complete and i have wondered that this scheme
may be available using reflection. In nested classes i can use reflection to
get the parent class in which the nested class is defined. It's reasonable
to think that reflection may be also used to know is a given object is part
of other as a property.

Thanks

See my response to Moty Michaely.

Thanks anyway

"Patrice" <http://www.chez.com/scribe/> escribió en el mensaje
news:%23YZlOjsoHHA.5032@TK2MSFTNGP02.phx.gbl...
[quoted text, click to view]

You could use the same object instance at multiple places (i.e. you don't
have *one* parent anyway that .NET could track down). You don't have this
kind of relation between object *instances* (don't confuse this with
inheritance that defines just a "static" relationship between *classes*).

You may want to post about what exactly is this design. If you get back
always to the root you could keep a reference to the root in each object so
that you could something like :

Me.Root.DataSet

You could also use a helper method à la FindControl (something that would
find the nearest parent node of a particular type, for example).

You may want to explain what you are trying to model. Someone could came
with a better design (in particular it's quite unusual to know exactly at
which deep level you are for a tree like structure).

--
Patrice

"news.microsoft.com" <ricardo@microsoft.com> a écrit dans le message de
news: %23Q9fhB4oHHA.1776@TK2MSFTNGP05.phx.gbl...
[quoted text, click to view]