Trees are indeed a special case. Some trees are viewed as containers for objects, some just hold some text - sure the string is an object but it doesn't know what it represents. The lowest common denominator approach makes the node relatively dumb and gives the behavior to the tree.
Of course, nothing stops you from deriving from TreeNode and adding all kinds of behavior to your class. However, for events, the hashtable approach is what I use too. That puts the filtering code in one place. Charlie Poole [EMAIL PROTECTED] www.pooleconsulting.com www.charliepoole.org > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Griffiths > Sent: Monday, September 09, 2002 6:51 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] event granularity > > > Do you *really* want to have to attach an event handler for every single > node in a TreeView? That sounds like a massive overhead compared to one > event handler... > > When I do have one object that corresponds to each node in > something like a > tree view or an XML document, I just maintain a hashtable. So to give an > example where I agree with you - with the Toolbar control, I think it's > wrong that the Toolbar raises events not buttons. It's not a big > deal - my > event handler just looks something like this: > > private void toolBar_ButtonClick(object sender, > ToolBarButtonClickEventArgs e) { > MyObject obj = (MyObject) toolBarButtonToObject[e.Button]; > if (obj != null) obj.OnClick(); > } > > Looking an item up in a hashtable is not exactly a massive overhead. And > this requires you to hook the event just *once*. You seem to be proposing > that every object would be attached to the event handler. That > would indeed > be a massive overhead as you say. It would also be a mad thing to do. If > all the events are raised through a single object, why would you hook that > event handler more than once? Just have a single handler that locates the > object that you want to deal with the event, like the one above. > > For things like the TreeView I think that the way Microsoft has done it is > better than what you are proposing for most cases - the majority of tree > view click handling code I've written has used the same code for > most of the > nodes, so I wouldn't really want a seperate event handler for each node. > > > -- > Ian Griffiths > DevelopMentor > > ----- Original Message ----- > From: "Christian Schmitz" <[EMAIL PROTECTED]> > > > I have a problem with the location of events in the .NET framework. Why > > Microsoft locates the events in top level classes and not in the classes > > where the events really happens? For instance: TreeView raises > events, not > > the TreeNode or XMLDocument raises events not the XMLNode! I > think, it is > a > > bad concept to do it in this style. > > For example: If you have a large object model which holds it's > data in an > > XMLDocument and every object is linked in a 1:1 relationship to > a XMLNode- > > object how can I realize that the object "hears" what happens in its > > XMLNode? When I use the .NET style I would link every object to the > > XMLDocument and filter the suitable events. That means a tremendous > > overhead. > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
