As Ritesh pointed out, you have to provide the wiring yourself.
You have to write an event handler method that handles the event coming
from the tree view, and then raise your MyEvent method from within the
event handler.
However, your example wasn't exactly clear as to whether MyEvent was an
event belonging to the Form that owns the tree view, or whether it
belongs to some other class that is used in your Form.
If MyEvent belongs to some class other than your Form class, then you
have a different situation.
Conceptually, you want to tell this other class (which has no relation
to the tree view other than the fact that they're both used on the same
Form) that "something happened" that's of interest to it. We'll class
the class that owns MyEvent, MyClass. There are two ways to do this.
1. If the purpose of MyClass is to interact tightly with a tree view
and nothing but a tree view, and that's really all it does, it might be
appropriate to pass the tree view instance into MyClass and have it
connect up its own event handlers to the events of interest from the
tree view. This is a very tight coupling, and you should use it only
when MyClass and the tree view are tightly related, one-to-one, and
MyClass really doesn't mean anything without a companion tree view. Or,
preferably,
2. Write an event handler in your Form that listens to the tree view
event (as I mentioned at the start of the post), but then have that
event handler method call a SomethingHappened() method in your MyClass.
SomethingHappened() should be named _from the point of view of
MyClass_. In other words, how does MyClass see this thing?
As an example of #2, I have a class that as part of its job stores a
collection of customers that the user currently has selected. I also
have a list view with check boxes. The list view shows the customers,
one per row. If a customer is checked, then they are included in the
collection of selected customers. If a customer is not checked, then
they are not included. My class has methods called SelectCustomer() and
UnSelectCustomer(), _not_ CustomerCheckedInListView() and
CustomerUnCheckedInListView(), because my class couldn't care less how
the selection is represented on the screen, it cares only that a
customer was selected or un-selected.
It's the Form that provides the wiring between a user's action of
checking or un-checking a list view item and a call to SelectCustomer()
or UnSelectCustomer() in my other class, therefore it's the Form that
understands, conceptually, that "selected" is represented on the screen
by a checked list view item. This decouples presentation from business
logic.
