Correct. In other words, the tree can live without the Form.

You're right, I could do this. Though, isn't it interesting that it is not
possible to store the information I need to remember? I only want to
remember "I attached this handler to that event". I am able to remember
"this handler" because it's just a Delegate, but I am not able to rember
"that event" (without using reflection).

I can not belive that it is not possible.

Armin

And as a clarification for this point:

Even if you feel you must maintain a list of subscribed events, you do not  
need a new class for every event type.  All you need to keep is a list of  
the objects for which you've subscribed; all the other information is  
already known at compile time and can be referred to explicitly when you  
want to unsubscribe.

I don't think the typing should be an issue anyway, but it's not really  
required.  So if you object to it, don't do it.

Pete

To make it a bit shorter, I'll try to resume:
You twice say that it is not a problem (to immediatelly unsubscribe). So, we
can say that it is up to me. But if I have the choice between either listen
to an event that will never occur, or don't listen to it anymore, the latter
obviously makes more sense. That's the reason why I unsubscribe
immediatelly.

Why "references to references"? (I'm using VB.Net BTW) A reference to a
MulticastDelegate object is possible. The event is a MulticastDelegate
object. My only problem is that it is private in the class.
[Meanwhie I know what you might be referring to but I'm not sure yet; see my
example and the explanation at the end]

Sorry, I can not comment the C-Code.

Because it's more work. If I have to reference the object, I will have to
handle different
object types and different events individually. I just want a simple loop:

for each item in mylist
   removehandler ...
   -or-
   [delegate].Remove ...
next

Sort of p-Code, but that's all I am looking for.

Sorry, but everything makes sense and works well.

Yes, I did not include the whole code. The code explains well how I have to
handle the different events individually because the code is not based on a
base class (like MultiCastDelegate) that is common to all events, no matter
which object and no matter which event.

I don't remove anything twice. After removing the handler, I remove the item
from the list. If it's not in the list anymore, it won't be removed again
when the Form is destroyed.

You are right, the loop to find the item in the list was a quicky. Could be
a hashtable or whatever. But it doesn't matter. If you want to remove
something from a list, it has to be done.

Compared to

   class Item
       event as multitaskdelegate
       eventhandler as delegate
   end class

it is pretty much to type, and in real-world there are some more events, as
a consequence some more "Class HookedXYZEvent", and some more arraylist and
some more loops to process the arraylists. If I could keep it all in one
list (of course, without different types of list items), it would be simple
in one go.

[Later....]
An example how it (almost) works. Comments see below.

Public Class Form1

  Class C1
     Public Event Progress(ByVal p As Integer)
     Public ReadOnly Property MCD() As MulticastDelegate
        Get
           Return ProgressEvent
        End Get
     End Property
     Public Sub Raise()
        RaiseEvent Progress(0)
     End Sub
  End Class

  Class C2
     Public Event Done()
     Public ReadOnly Property MCD() As MulticastDelegate
        Get
           Return DoneEvent
        End Get
     End Property
     Public Sub Raise()
        RaiseEvent Done()
     End Sub
  End Class

  Private Class Item
     Public [event] As MulticastDelegate
     Public Handler As [Delegate]

     Public Sub New(ByVal [event] As MulticastDelegate, _
        ByVal Handler As [Delegate])

        Me.event = [event]
        Me.Handler = Handler
     End Sub
  End Class

  Private Sub Form1_Load(ByVal sender As System.Object, _
     ByVal e As System.EventArgs) Handles MyBase.Load

     Dim al As New List(Of Item)
     Dim o1 As New C1
     Dim o2 As New C2

     Dim d1 As New C1.ProgressEventHandler(AddressOf OnProgress)
     Dim d2 As New C2.DoneEventHandler(AddressOf OnDone)

     'add the event handlers...
     AddHandler o1.Progress, d1
     AddHandler o2.Done, d2

     '...and remember which events I handle.
     al.Add(New Item(o1.MCD, d1))
     al.Add(New Item(o2.MCD, d2))

     o1.Raise()
     o2.Raise()

     '...
     'later: Remove all event handlers

     For Each i As Item In al
        [Delegate].Remove(i.event, i.Handler)
     Next

     o1.Raise()
     o2.Raise()

  End Sub
  Private Sub OnProgress(ByVal p As Integer)
     MsgBox("OnProgress")
  End Sub
  Private Sub OnDone()
     MsgBox("OnDone")
  End Sub

End Class

Comments:
- You see that the MCD properties make the internal MCDs public.
- This enables me storing a reference on them externally.
- This is usually not done, but only in this example. At least it is not
possible with classes authored by somebody else.
- The main point: In the loop that removes the handles, I don't have to care
about the object types and the events. All in one go! In addition: I don't
have to write one Item class for each event I want to handle.

Though, why I wrote it "almost" works: What I did not know until know is
that the invocation list of a MultiCastDelegate object (MCD) seems to be
readonly. I can only remove one item from the invocation list by creating a
new MCD. As a consequence, I would have to store the new MCD back in the
object - which is obviously not an option and not possible at all for
foreign classes.

Bottom line, the example shows how to store the information that I want to
store: I want to remember that I added /this/ handler to /that/ event
without individual handling different objects and events because the
event concept is the same for all of them. I also think that the example
makes clear what was my intention, and that it is - almost - possible. :-)

Please don't get me wrong: I use .Net since the first public SDK preview (in
Y2K?), and I am a programmer for 20 years now, so I (usually ;-) ) know what
I do. I don't insist on anything, but I thought that events have a common
concept, common base clases, and therefore it's not absurd to
think..uhhm..what I think. Now it turned out that under the hood called
"Events" there is something going on that makes it impossible to work as
intended.

Anyways, thanks a lot for your time and trying to help!

Armin