Adding own event handler in front of other event handlers

It is more of an implementation detail of VB.NET, it has an alternate way of dealing with events using the WithEvents and Handles keywords. An event handler that uses Handles gets subscribed by auto-generated code in the form constructor. This code will run before any of your code, including InitializeComponent or your custom AddHandler statement. And will thus always run first.

Getting your code to guarantee to run first is possible. Derive your own class from Button and override the OnClick method:

Public Class MyButton
    Inherits Button

    Protected Overrides Sub OnClick(ByVal e As System.EventArgs)
        '' Do your stuff here
        ''....

        '' Other event handlers will run now:
        MyBase.OnClick(e)
    End Sub
End Class

The order of execution of handlers of a single event cannot be controlled through the basic behavior of a built-in event itself. MulticastDelegates are "bags" of handlers, and they just grab them one at a time. Keep in mind that this is how most developers expect this to work, and it can be dangerous to allow order-dependent event handlers. Event handlers should normally not know about each other, because if they are dependent on being executed before or after another handler, they first have to know of the existence of the other handler (violating information hiding and several other design principles), and second, if that order changes, the behavior will be broken.

If you understand all this, and still want to control the order of execution of handlers of an event, the following will get you close.

1. Create an ordered collection of delegates of the event handler type called MyHandlers. This will be a surrogate for the actual event's MulticastDelegate implementation.
2. Create a "master" handler method that will actually be attached to the built-in event, and will iterate through MyHandlers and call each one.
3. Define some means to add and remove handlers from the list. Some of this can be accomplished with a custom event "property", but that will define only add and remove behaviors, not insert.

The code might look like the following:

private List<EventHandler> MyHandlers = new List<EventHandler>();

private void MasterClickHandler(object sender, EventArgs e)
{
   foreach(var handler in MyHandlers)
      handler(sender, e); 
}

public event EventHandler MyControlButtonClick
{
   add { MyHandlers.Add(value); }
   remove { MyHandlers.Remove(value); }
}

public void InsertButtonClickHandler(EventHandler handler)
{
   MyHandlers.Insert(handler,0); //calling this to add a handler puts the handler up front
}

...

myForm.MyControl.Click += MasterClickHandler;

Notice that you're no longer attaching handlers other than MasterClickHandler to the actual event; you can't have your cake and eat it too, both overriding and keeping the basic event behavior. There also isn't an "insert" behavior built into the event "property"; you have to define a method that allows this. Lastly, you should never raise the event MyControlButtonClick directly (though as your control is the only one that can, this can be enforced by code inspection).

Now, when you click the button, the button's built-in Click event fires MasterEventHandler, which will execute the delegates in MyHandlers in the same order they were attached to MyControlButtonClick (with any that were inserted executed first, in the reverse order they were inserted). If you placed this code in a custom user control with the Button, you could even name the custom event on your control Click, and the control would look and work much like the Button it contains, except that it would have the extra control over inserting handlers. The beauty of the whole thing is that nothing about this code forces consumers to work with it as anything other than a plain ol' vanilla event.

Not easily.

That being said, don't do it. Your code shouldn't care about what order it's called in - it should just care that the button in question was clicked. All of the handlers, including yours, will execute. If the order is important, you should rethink your design, and use some other mechanism to control that.

I had a similar problem.

I had an event: Closed that two different objects listen to. And I had to be sure that the 1st object's event will be called before the 2nd one.

Here his my solution (in C#):

public class Screen
{
    public event EventHandler Closed;
    public event EventHandler ScreenRemoved;


    protected virtual void OnClosed()
    {
        if (Closed != null)
        {
            Closed.Invoke(this, EventArgs.Empty);
        }

        OnScreenRemoved();
    }

    protected virtual void OnScreenRemoved()
    {
        if (ScreenRemoved != null)
        {
            ScreenRemoved.Invoke(this, EventArgs.Empty);
        }
    }
}

This way for all the events I want to be called first:

m_Screen.Closed += Screen_Closed;

And for all the events I want to be called last:

m_Screen.ScreenRemoved += new EventHandler(Screen_Closed);

*both way adding an event are the same, with and without "new EventHandler()"

Hope I been helpful.