Question

I have a base class, a middle class that inherits from the base, and a top class that inherits from the middle class. I defined an event in the base class and raise it from a method. I defined a handler in the middle class for the base class event, and also the same handler in the top class.
When the event fires, the middle class handler gets hit first, then the top class handler.

If I keep adding more classes to the chain (ultra inherits from top, supreme inherits from ultra, etc.), the event handlers keep getting called in the most basic classes first (e.g., middle, top, ultra, supreme).

Does this sequence always hold?
If not, what could / would make it go in a different order?

The order I’m observing suits this function perfectly; I just want to make sure it will work consistently.

I understand events are not guaranteed to fire in any order, BUT this is something the framework knows about at compile time, and as the author of the code I can say there will be no adding / removing of delegates at runtime for this event, nor will the event be consumed outside the base and it’s subclass chain; in fact, it’s protected.

I don’t know what happens behind the scenes, but maybe it sets the sequence during compile and therefore at run-time it’s a done deal?

EDIT: I’m adding the sample for clarity of what I’m doing.

Public Class BaseClass

  Protected Event Hello(ByRef Cancel As Boolean)

  Public Sub SayHello()
    Dim Cancel As Boolean
    RaiseEvent Hello(Cancel)
  End Sub

End Class

Public Class MiddleClass
  Inherits BaseClass

  Private Sub MiddleClass_Hello(ByRef Cancel As Boolean) Handles Me.Hello
    'This appears to always get called first
  End Sub

End Class

Public Class TopClass
  Inherits MiddleClass

  Private Sub TopClass_Hello(ByRef Cancel As Boolean) Handles Me.Hello
    'This appears to always get called second
  End Sub

End Class

Public Class UltraClass
  Inherits TopClass

  Private Sub UltraClass_Hello(ByRef Cancel As Boolean) Handles Me.Hello
    'This appears to always get called third
  End Sub

End Class

'...and so on

Answer 1

In your particular code sample, the order will behave how you expect.

When you have a method that’s marked as Handles Me...., all the VB compiler does is stick a hidden AddHandler statement at the very beginning of your constructor. Constructors run from the base type to derived type, and so the hidden AddHandler for the base types will run before the AddHandler in the derived types. As long as your RaiseEvent were to raise events in the order the handlers were added, then yes, you’ll see the order you see now. For simple VB events like you have, that behavior is highly unlikely to change.

Observe my caveat above: if the event was not a simple event but rather a Custom Event where the base class can specify it’s own behavior for AddHandler and RaiseEvent, all bets are off. Nothing would prevent me from making my own RaiseEvent that runs handlers in any random order I want (assuming it even runs them all!) If the Base class isn’t something you own, I would be careful if you assume ordering.

In general, event handlers that have subtle ordering requirements can often create hard-to-debug bits of code. It’s best avoided if you can. If the base/derived ordering is important, you might be able to make the code clearer by using overridden methods and have derived types call MyBase in the appropriate place.