3

I have a method

protected void Item_Click(object sender, EventArgs e)
{     }

I wanted that other code to call this method. ( didn't really need the sender nor e)

something like :

Item_Click(null, null)

But then I remembered I can use EventArgs.Empty instead.

Mouse hovering over it shows :

enter image description here

Wait...What ?

EventArgs.Empty represents an event ? it is not. it should represent empty argument not an event.

just like string.empty represent empty string.

  • Am I missing something here?
Royi Namir
  • 144,742
  • 138
  • 468
  • 792

1 Answers1

4

It's just poor documentation, conflating two concepts in one word. The latest documentation seems a little better:

Provides a value to use with events that do not have event data.

The trouble is that "an event" has two separate meanings:

  • The event that you can subscribe to
  • A single "instance" of that event being raised

For example, it wouldn't be unreasonable to say: "Subscribe to the KeyPress event to receive keyboard-related events."

(The word "delegate" is just as bad, used to describe delegate types and instances of them.)

It's all unfortunate, but rest assured that you have the right idea.

As an aside, if you want to call the method other than when the event is raised, I'd potentially separate it into two methods:

// This only exists to handle the event, delegating to the DoSomething method
private void HandleItemClicked(object sender, EventArgs e)
{
    DoSomething();
}

// This can be called from other code, and should be named according to what it
// does.
private void DoSomething()
{
}

If you're subscribing to the event manually, you don't even need the extra method:

item.Click += delegate { DoSomething(); };

This way you make it clear that your "real" method doesn't care about the sender or event args, and you don't need to provide "dummy" values when calling it.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • @RoyiNamir: Absolutely not. KeyPress is an event, not a delegate instance. – Jon Skeet May 02 '13 at 09:01
  • Jon , but isn't event is just an accesor keyword for a delegate ? So subcribing to event is like subscribing to delegate , but with extra restrictions ( += vs = etc ) – Royi Namir May 02 '13 at 09:27
  • @RoyiNamir: No, it's not. It's like the difference between a property and a field. Please read http://csharpindepth.com/Articles/Chapter2/Events.aspx – Jon Skeet May 02 '13 at 09:28
  • Jon Hi. I've read it (twice). but I don't fully understand why you said my last comment is completely wrong. besides the fact of -what code does the compiler emits for the event keyword ( add and remove ) -- event _is_ a keyword which ,at the end , adds restriction like : **1)** _it can only be invoked from within the class that declared it_ **2)** I can't use `=` from outer class and destroy the invocation list, i'll must use `+=` instead **3)** interface usages (true for events , but not for delegates).am I wrong ?....(or should i ask it as a new question). – Royi Namir May 02 '13 at 12:22
  • @RoyiNamir: You need to separate out "field-like events" from "events in general". A general "event" is like a property, except that instead of get/set, it has add/remove (and always both) - and the type must be a delegate type. That's *all* it is. You don't have to have *any* backing field, although it would be pointless to do so. It sounds like you may need to ask a new question. – Jon Skeet May 02 '13 at 12:32