469,609 Members | 1,666 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,609 developers. It's quick & easy.

Parent reference (cross link) problem

Hi

It's a little hard for me to explain my problem, but i'll try. I have
an application in which i have a ManagerClass, many ClientClass-es ans
some ControlClass.
The ManagerClass creates one or more instances of ClientClass.
ClientClass creates some controls from ControlClass.
In the ControlClass i have derived some common control classes and
added some functionalities.

Here comes the problem:
when one Event handler from COntrolClass is fired , i need it to be
treated by the ManagerClass , depending on the state of the ClientClass
and the ControlClass that generated that event.

My approach , so far is working , but i'm sure it's not the best way to
do it , as i'm having lots of cross references:
the ClientClass is in a dll file, and i have it as a reference in
ManagerClass, so i can create instances of ClientClass from the
manager.
In ClientClass, in order to call a Method from the ManagerClass, i have
a reference to the ManagerClass, passed to the ClientClass Constructor.

THe same problem is with ControlClass and client class, same mechanism
used. is there any other way that i can do this?
thx

Nov 17 '05 #1
2 1329
Sidorf,

Correct me if I am wrong but it sounds as thought you have a parent child
relationship between your ManagerClass and the ClientClass and a parent
grandchild relationship between your ManagerClass and your ControlClass that
is contained in the ClientClass.

Your goal is to have notifications from ClientClass to your ManagerClass and
notifications from your ControlClass to the ManagerClass. So you want to
'bubble' events of importance from classes contained within other classes.

You should check using 'events' and 'delegates' in the .Net framework -
these are mechanism that allow you fire notifications to interested parties.
So you could setup an event on your ClientClass that is monitored by your
ManagerClass and you could also set up an event on your ClientClass that
fires when a ControlClass is added to the ClientClass have this monitored by
the ManagerClass and hence you can then setup another monitor for events on
the ControlClass - hope that isn't to confusing!

The approach described above does not require any of the children in the
parent child relationships to have an explicit reference to the parent.

http://msdn.microsoft.com/msdnmag/issues/01/08/net/
http://weblogs.asp.net/rosherove/arc...28/100444.aspx
http://www.codeproject.com/csharp/De...sAndEvents.asp

Check the links below:
HTH

Ollie Riches
"Sidorf" <ci************@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Hi

It's a little hard for me to explain my problem, but i'll try. I have
an application in which i have a ManagerClass, many ClientClass-es ans
some ControlClass.
The ManagerClass creates one or more instances of ClientClass.
ClientClass creates some controls from ControlClass.
In the ControlClass i have derived some common control classes and
added some functionalities.

Here comes the problem:
when one Event handler from COntrolClass is fired , i need it to be
treated by the ManagerClass , depending on the state of the ClientClass
and the ControlClass that generated that event.

My approach , so far is working , but i'm sure it's not the best way to
do it , as i'm having lots of cross references:
the ClientClass is in a dll file, and i have it as a reference in
ManagerClass, so i can create instances of ClientClass from the
manager.
In ClientClass, in order to call a Method from the ManagerClass, i have
a reference to the ManagerClass, passed to the ClientClass Constructor.

THe same problem is with ControlClass and client class, same mechanism
used. is there any other way that i can do this?
thx

Nov 17 '05 #2
Hi Ollie
thanks for your quick reply. Seems like a solution to my problem. i'll
do some reading now and i'll post any further quiestions on delegates
issue.
Thanks again

Nov 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.