Events

[tshad]

I was looking at events and have the following code:

***************************************************8
using System;

//declaring the event handler delegate
delegate void ButtonEventHandler(object source, int clickCount);

class Button
{
//Event Handler function
public void onButtonAction(object source, int clickCount)
{
Console.WriteLine("Inside Event Handler !!!");
}

//declaring the event
public event ButtonEventHandler ButtonClick;

//Function to trigger the event
public void clicked(int count)
{
Console.WriteLine("\nInside Clicked !!!");
//Invoking all the event handlers
if (ButtonClick != null) ButtonClick(this, count);
}
}
public class Dialog
{
public Dialog()
{
Button b = new Button();

//Adding an event handler
b.ButtonClick += new ButtonEventHandler(b.onButtonAction);
//Triggering the event
b.clicked(1);

b.ButtonClick += new ButtonEventHandler(b.onButtonAction);
b.clicked(1);

//Removing an event handler
b.ButtonClick -= new ButtonEventHandler(b.onButtonAction);
b.clicked(1);

b.ButtonClick -= new ButtonEventHandler(b.onButtonAction);
b.clicked(1);
}
static void Main()
{
new Dialog();
Console.Read();
}
}
******************************************************

Here you have the onButtonAction as part of the Button class. So it has to
be defined as b.onButtonAction.

You can also do it with the handler outside of the Button Class:
**********************************************************
using System;

//declaring the event handler delegate
delegate void ButtonEventHandler(object source, int clickCount);

class Button
{
//declaring the event
public event ButtonEventHandler ButtonClick;

//Function to trigger the event
public void clicked(int count)
{
Console.WriteLine("\nInside Clicked !!!");
//Invoking all the event handlers
if (ButtonClick != null) ButtonClick(this, count);
}
}
public class Dialog
{
public Dialog()
{
Button b = new Button();

//Adding an event handler
b.ButtonClick += new ButtonEventHandler(onButtonAction);
//Triggering the event
b.clicked(1);

b.ButtonClick += new ButtonEventHandler(onButtonAction);
b.clicked(1);

//Removing an event handler
b.ButtonClick -= new ButtonEventHandler(onButtonAction);
b.clicked(1);

b.ButtonClick -= new ButtonEventHandler(onButtonAction);
b.clicked(1);
}
static void Main()
{
new Dialog();
Console.Read();
}

//Event Handler function
public void onButtonAction(object source, int clickCount)
{
Console.WriteLine("Inside Event Handler !!!");
}
}
********************************************************

Here I define it just as onButtonAction.

Which way is the way it is normally done?

Thanks,

Tom

 

[Peter Duniho]

[...]
Here I define it just as onButtonAction.

Which way is the way it is normally done?

Wow. That's a whole lotta code just to ask a relatively simple,
straightforward question. Next time, you might consider doing a little
editing.

In any case, the simple answer to your question is that there's not really
a "normal" way as you're asking it. It's not uncommon in a VS
Designer-created application to have the handlers in the same class where
the event is declared. For example, people writing event handlers for
events that are raised by the Form itself, handlers that go into the Form
class by default.

On the other hand, in those very same applications, it's also not uncommon
for an event handler to be in the Form class (since, again, that's where
they wind up by default) when it's handling an event on a different class
(for example, a Click event handler for a button control in the form
itself).

Now, that said, in spite of that my own personal preference is to
generally only subscribe to the event from outside the class, using a
handler in a different class. The reason being that from within the class
there's usually a better way to hook into the execution flow when
something that raises the event would happen (or at least there should
be). For example, if you're handling any event on the Form class, and
you've already got a sub-class of Form, there's a virtual function related
to the event (usually called "OnXXXX" where "XXXX" is the name of the
event) that you can override.

When I'm handling an event raised by a Form, and I'm sub-classing that
Form, I override the virtual function rather than subscribe to the event.

So architecturally, I view events as a way to expose things that happen to
the world outside a class. From within the class, I use whatever internal
mechanism is offered (or for my own classes, I provide it and use it).

However, lots of people use events by default, overriding a virtual
function only when they really have to, and frankly I don't see anything
really all that bad about doing it that way. Going through the event is
going to be less performant, but only nominally...it's not the kind of
thing that you'd ever notice in 99.9% of the situations.

So, what works best for you? What best fits your own mental model of how
the event paradigm behaves, and which way do you find the clearest to code
and to read? IMHO, either answer is "correct", and you should have a very
good reason for implementing something the other way (i.e. a reason much
better than "so-and-so does it that other way" ).

Pete

 

[tshad]

[...]
Here I define it just as onButtonAction.

Which way is the way it is normally done?

Wow. That's a whole lotta code just to ask a relatively simple,
straightforward question. Next time, you might consider doing a little
editing.

Actually, I usually do. I just wanted to show the exact same code show 2
different ways to get my point across of what I was asking.

In any case, the simple answer to your question is that there's not really
a "normal" way as you're asking it. It's not uncommon in a VS
Designer-created application to have the handlers in the same class where
the event is declared. For example, people writing event handlers for
events that are raised by the Form itself, handlers that go into the Form
class by default.

On the other hand, in those very same applications, it's also not uncommon
for an event handler to be in the Form class (since, again, that's where
they wind up by default) when it's handling an event on a different class
(for example, a Click event handler for a button control in the form
itself).

Now, that said, in spite of that my own personal preference is to
generally only subscribe to the event from outside the class, using a
handler in a different class. The reason being that from within the class
there's usually a better way to hook into the execution flow when
something that raises the event would happen (or at least there should
be). For example, if you're handling any event on the Form class, and
you've already got a sub-class of Form, there's a virtual function related
to the event (usually called "OnXXXX" where "XXXX" is the name of the
event) that you can override.

When I'm handling an event raised by a Form, and I'm sub-classing that
Form, I override the virtual function rather than subscribe to the event.

So architecturally, I view events as a way to expose things that happen to
the world outside a class. From within the class, I use whatever internal
mechanism is offered (or for my own classes, I provide it and use it).

However, lots of people use events by default, overriding a virtual
function only when they really have to, and frankly I don't see anything
really all that bad about doing it that way. Going through the event is
going to be less performant, but only nominally...it's not the kind of
thing that you'd ever notice in 99.9% of the situations.

So, what works best for you? What best fits your own mental model of how
the event paradigm behaves, and which way do you find the clearest to code
and to read? IMHO, either answer is "correct", and you should have a very
good reason for implementing something the other way (i.e. a reason much
better than "so-and-so does it that other way" ).

I agree, but it is good to see if there is a standard way of doing (and why)
before making that decision as it may be easier to do or maintain for others
that have to use the code.

Thanks,

Tom

 

[Peter Duniho]

[...]
Here I define it just as onButtonAction.

Which way is the way it is normally done?

Wow. That's a whole lotta code just to ask a relatively simple,
straightforward question. Next time, you might consider doing a little
editing.

Actually, I usually do. I just wanted to show the exact same code show 2
different ways to get my point across of what I was asking.

Here's a more concise example:

class A
{
public event EventHandler EventA;

public A()
{
EventA += HandlerA;
}

private void HandlerA(object sender, EventArgs e) { }
}

class B
{
private A a = new A();

public B()
{
a.EventA += HandlerA;
}

private void HandlerA(object sender, EventArgs e) { }
}

Class A subscribes to its own event. Class B subscribes to class A's
event. This sample shows exactly the same two different ways you're
talking about, in much less code and without any extraneous stuff to
distract from the question (like calls to Console.WriteLine(), multiple
subscriptions to the event, etc.).

Pete