Events: Advanced Patterns & Custom EventArgs

By the end of this lesson you'll be able to design professional, type-safe events: carry rich data with a custom EventArgs, raise events the standard .NET way with a protected virtual OnXxx method, do it safely on multiple threads, and avoid the memory leaks that catch out even experienced developers.

1. Custom EventArgs — Carrying Data With an Event

A bare event can shout "something happened!", but real apps need to know what happened. You attach that detail by creating a class that inherits from EventArgs and declaring the event as EventHandler<YourEventArgs>. By convention the data class ends in EventArgs and its properties are read-only (set once in the constructor) so a subscriber can't tamper with the data other subscribers will receive. Read this worked example and run it, then you'll write your own.

using System;

// A custom EventArgs subclass CARRIES DATA to every subscriber.
// Convention: the class name ends in "EventArgs" and the
// properties are read-only (set once in the constructor).
class OrderEventArgs : EventArgs
{
    public string OrderId { get; }
    public decimal Amount { get; }
    public DateTime Placed { get; }

    public OrderEventArgs(string orderId, decimal amount)
    {
        OrderId = orderId;
        Amount = amount;
        Placed = DateTime.Now;
    }
}

// Th
...

Your turn. Define an EventArgs subclass that carries a message, then raise an event with it. Fill in the three blanks marked ___ using the // 👉 hints, then run it.

using System;

// 🎯 YOUR TURN #1 — define a custom EventArgs and raise an event.

// 1) Finish this EventArgs subclass so it CARRIES a message string.
class AlertEventArgs : ___          // 👉 inherit from EventArgs
{
    public string Message { get; }
    public AlertEventArgs(string message) => Message = message;
}

class Alarm
{
    // 2) Declare an event using the generic standard delegate.
    public event EventHandler<AlertEventArgs>? Triggered;   // (already done)

    public void Fire(s
...

2. Subscribing — Reading the Event Data

Defining the data is only half the job; a subscriber has to read it. Every handler receives two arguments: sender (the object that raised the event) and e (your EventArgs). You reach the details through e — e.OrderId, e.Amount, e.Points, whatever your class exposed. Fill in the two blanks below: choose the operator that adds a subscriber, and pull the value off e.

using System;

class ScoreEventArgs : EventArgs
{
    public int Points { get; }
    public ScoreEventArgs(int points) => Points = points;
}

class Game
{
    public event EventHandler<ScoreEventArgs>? ScoreChanged;
    public void AddPoints(int points)
        => ScoreChanged?.Invoke(this, new ScoreEventArgs(points));
}

class Program
{
    static void Main()
    {
        var game = new Game();

        // 🎯 YOUR TURN #2 — subscribe a handler that READS the event data.

        // 1) Use the 
...

3. The protected virtual OnXxx Raise Method

In professional code you almost never raise an event inline. Instead you funnel every raise through a single protected virtual method named On + the event name — OnPriceChanged, OnOrderPlaced. There are two reasons. protected lets a subclass raise the event too (handy for base classes). virtual lets a subclass override the method to add behaviour — log it, suppress it, run code before or after — without touching the property that triggered it. It also gives you exactly one place to make the raise thread-safe.

using System;

class PriceChangedEventArgs : EventArgs
{
    public decimal OldPrice { get; }
    public decimal NewPrice { get; }
    public PriceChangedEventArgs(decimal oldPrice, decimal newPrice)
    {
        OldPrice = oldPrice;
        NewPrice = newPrice;
    }
}

class Stock
{
    public event EventHandler<PriceChangedEventArgs>? PriceChanged;

    private decimal _price;
    public decimal Price
    {
        get => _price;
        set
        {
            if (_price == value) return;
...

4. Thread-Safe Raising & Unsubscribing

There's a subtle race condition when events are used across threads. Between checking that an event has subscribers and actually calling it, another thread could unsubscribe the last handler — leaving you calling null. The fix is to copy the event into a local variable first, then call the copy. Good news: the ?.Invoke operator you've been using already does this copy for you, which is the main reason it's the recommended way to raise. The example also shows the other half of subscription hygiene: a named handler so you can -= it later (you can't unsubscribe an anonymous lambda).

using System;

class TickEventArgs : EventArgs
{
    public int Tick { get; }
    public TickEventArgs(int tick) => Tick = tick;
}

class Clock
{
    public event EventHandler<TickEventArgs>? Ticked;

    protected virtual void OnTicked(TickEventArgs e)
    {
        // THREAD-SAFE RAISE: copy the event to a local variable first.
        // Another thread could unsubscribe the last handler between the
        // null-check and the call; the local copy can't be changed
        // out from under y
...

// LEAK: long-lived publisher keeps 'view' alive forever
service.DataUpdated += view.Refresh;

// FIX: unsubscribe when done (e.g. in Dispose)
service.DataUpdated -= view.Refresh;

// Pass the SAME reference you subscribed with — a fresh lambda
// like  (s,e) => view.Refresh(s,e)  is a NEW object and won't detach.

using System;

// 🎯 MINI-CHALLENGE: a TemperatureSensor that raises ThresholdExceeded
//
// 1. Create a custom EventArgs class "ThresholdEventArgs" that carries
//    a  double Value  (set it in the constructor, read-only property).
// 2. Give TemperatureSensor an event:
//        public event EventHandler<ThresholdEventArgs>? ThresholdExceeded;
//    ...and a  double Threshold  property (e.g. 30.0).
// 3. Add a method  Report(double value)  that prints the reading, and if
//    value > Thresho
...