OnClick event name

  • Thread starter Thread starter tshad
  • Start date Start date
T

tshad

***************************************************
public class UserControl1 : System.Windows.Forms.UserControl {
// ...

public event EventHandler OnClick;

// ...

public void SomeFuncWhichFiresClickEvent() {
// ...

// fire event
if (OnClick != null)
OnClick(this, new EventArgs());
}

// ...

}public class UserControl1 : System.Windows.Forms.UserControl {

// ...

public event EventHandler OnClick;
// ...

public void SomeFuncWhichFiresClickEvent() {
// ...

// fire event
if (OnClick != null)
OnClick(this, new EventArgs());
}
// ...
}
**************************************************

I am curious about the naming of EventHandlers.

Normally you see and event preceeded with the word "On" (OnClick,
OnSelect,...)

In the above, OnClick could be anything, right? It doesn't have to have the
"On" in front of it.

Is this just a convention or is it required?

I would follow this, but I am curious if it has to be that way?

Thanks,

Tom
 
tshad said:
[...]
I am curious about the naming of EventHandlers.

Normally you see and event preceeded with the word "On" (OnClick,
OnSelect,...)

In the above, OnClick could be anything, right? It doesn't have to have the
"On" in front of it.

Is this just a convention or is it required?

I would follow this, but I am curious if it has to be that way?
Click to expand...

Not only does it not have to be that way, I am skeptical that you've
found any significant number of examples of events named that way.

Typically, the "OnXXX" name is used in the _method_ that raises the
event, not the event itself. In that convention, "XXX" is the event
name, and "OnXXX" is the name of the method.

Even in that case, while that is a convention Microsoft follows and
recommends, IMHO it's not a very good one. I prefer "RaiseXXX" for the
method name, as to me the word "on" implies something that happens as a
consequence of the event being raised, not the other way around.

You are, of course, free to name your events, delegate types, and
related methods whatever you want. You don't even have to use the
standard .NET method signature for your events (i.e. "(object sender,
EventArgs e)")…any valid delegate type will do. It's useful to follow
the .NET convention IMHO when practical, but some events have no need
for that structure and it's fine to do it some other way if so.

Pete
 
Hi!

I am curious about the naming of EventHandlers.
Click to expand...
Normally you see and event preceeded with the word "On" (OnClick,
OnSelect,...)
Click to expand...
In the above, OnClick could be anything, right? It doesn't have to
have the "On" in front of it.
Click to expand...
Is this just a convention or is it required?
Click to expand...
I would follow this, but I am curious if it has to be that way?
Click to expand...

It is just a convention and you can use all names you want. But
Microsoft was thinking, what could be a good guideline for a developer
and wrote that down.
http://msdn.microsoft.com/en-us/library/ms229042.aspx

You can use it or simply ignore it. Normaly it is a good idea to simply
read it and try to go that way, too. But if you see any reason, why you
want to do something a little different: Feel free to do it! But knowing
the guidelines is always a good idea when you want to give a library
away to other developers. They will be used to the nameing standards of
Microsoft.

But maybe you have some reasons to do it in some other way (e.g. the
whole team is used in giving the type first so you simply use stuff like
pszNiceName for a pointer to a zero terminated string).

So in your case, we can simply have a look at the Events of
System.Windows.Forms.Button:
- The Events itself are called: Click, DoubleClick, KeyUp, KeyDown, ....
So they directly give in their name, what is happening.
- Functions that consume the event are called OnClick, OnDoubleClick,
..... So you see directly when you read the code: "On" a "Click" this is
done ....
(So it is not the Event that is named with "On" as you did in your Code
example if I have it correctly in mind now... It would be "public event
EventHandler Click")

I hope that helped a little bit.

With kind regards,

Konrad
 
Konrad said:
[...]
So in your case, we can simply have a look at the Events of
System.Windows.Forms.Button:
- The Events itself are called: Click, DoubleClick, KeyUp, KeyDown, ....
So they directly give in their name, what is happening.
- Functions that consume the event are called OnClick, OnDoubleClick,
..... So you see directly when you read the code: "On" a "Click" this is
done ....
Click to expand...

Minor clarification: the above isn't quite correct. Using Visual Studio
with Forms events, the "functions that consume the event" are generally
named in the form "xxxN_yyy" where "xxxN" is the name of the field
referencing the object with the event itself (e.g. "textBox1") and "yyy"
is the name of the event (e.g. "TextChanged").

Those are the functions (methods) that _consume_ (i.e. subscribe to) the
event. They are named by the Designer, and of course you can write any
method from scratch to subscribe to the event.

The methods that _raise_ the event are the ones that start with "On…".
They can also be used to react to the raising of the event from within
the class where the event exists, but they aren't consuming the event
per se.

As an extreme example, in the sub-class you could modify the "On…"
override in your own class to not raise the event at all (e.g. by not
calling the base implementation); obviously if the event isn't raised,
it can't be consumed. :)

Pete
 
Hi Peter!

Peter Duniho said:
Konrad said:
[...]
So in your case, we can simply have a look at the Events of
System.Windows.Forms.Button:
- The Events itself are called: Click, DoubleClick, KeyUp, KeyDown,
.... So they directly give in their name, what is happening.
- Functions that consume the event are called OnClick, OnDoubleClick,
..... So you see directly when you read the code: "On" a "Click" this
is done ....
Click to expand...
Click to expand...
Minor clarification: the above isn't quite correct. Using Visual
Studio with Forms events, the "functions that consume the event" are
generally named in the form "xxxN_yyy" where "xxxN" is the name of the
field referencing the object with the event itself (e.g. "textBox1")
and "yyy" is the name of the event (e.g. "TextChanged").
Click to expand...

Thank you for that clarification. You are right that VisualStudio gives
it this name. And we refactor it always in our team to a On.... Syntax.
The methods that _raise_ the event are the ones that start with "On…".
They can also be used to react to the raising of the event from within
the class where the event exists, but they aren't consuming the event
per se.
Click to expand...
As an extreme example, in the sub-class you could modify the "On…"
override in your own class to not raise the event at all (e.g. by not
calling the base implementation); obviously if the event isn't raised,
it can't be consumed. :)
Click to expand...

Right. Good that you pointed that out. The full design pattern in our
team is:

Inside the Class that wants to raise an Event (e.g. a Click to make it
easier), we have:
- the event Click
- the function OnClick (in which you find something like if (Click !=
null) Click(this, ....) to raise the event)
- Whenever we want to raise the Click event, we call OnClick.
The big advantage of this design is, that you can derive from this class
and simply modify what is done on all these events.
(So there is no need to subscribe your own events.)

When we want to consume some event, then we again use the On...Click
Naming. But of course we have to add, what click we want to consume:
e.g. OnCancelClick.
(This has also the advantage, that you have more or less a command
related function. The nameing of visual studio has a control inside, but
you can have multiple controls that give the same command e.g. a menu
item and a button.)

It is interesting, what details can be forgotten, when you try to write
something down quickly. We are only a very small team and we never wrote
such stuff down so far (It more or less lives when we do code reviews
and refactor stuff if required!)

Peter: Is that more complete or did I get something wrong / forgot
something important? (It is always great to get these clarifications and
deeper insights of you. I always learn a lot from that because you
directly point me to stuff where I lack wisdom or didn't state something
correct! When reading a book or self-paced training kit, you get a nice
view into something but some details are always missing. I just hope
that I am not to anoying and that my english is not to bad :) )

So thank you for your time and answer.

With kind regards,

Konrad
 
Konrad said:
[...]
Inside the Class that wants to raise an Event (e.g. a Click to make it
easier), we have:
- the event Click
- the function OnClick (in which you find something like if (Click !=
null) Click(this, ....) to raise the event)
- Whenever we want to raise the Click event, we call OnClick.
The big advantage of this design is, that you can derive from this class
and simply modify what is done on all these events.
(So there is no need to subscribe your own events.)

When we want to consume some event, then we again use the On...Click
Naming. But of course we have to add, what click we want to consume:
e.g. OnCancelClick.
[...]
Peter: Is that more complete or did I get something wrong / forgot
something important?
Click to expand...

In terms of naming conventions, it seems to me you've covered it,
including sharing your own team's conventions (I agree, the
Designer-provided names are poor, implying a connection to a specific
instance of an object that may or may not exist). It's always helpful
to see what others have chosen as their convention when the language
doesn't provide a specific requirement.

I will point out that your abbreviated description of what you'd find in
the event-owning class's "On…" method is of a non-thread-safe
implementation. But of course, that's not really a problem with your
post, since we aren't really discussing the specifics of the
implementation for raising an event. So my comment is really just that
I tend to take any opportunity to make that point, rather than any sort
of criticism of your post. :)

Pete
 
Hi Peter!

I will point out that your abbreviated description of what you'd find
in the event-owning class's "On…" method is of a non-thread-safe
implementation. But of course, that's not really a problem with your
post, since we aren't really discussing the specifics of the
implementation for raising an event. So my comment is really just
that I tend to take any opportunity to make that point, rather than
any sort of criticism of your post. :)
Click to expand...

Criticism must not be negative. It is better to learn something in here
than learning through a bug that went through all tests to the customer
:)

Thank you for all your input / clarification.

With kind regards,

Konrad
 
Back
Top