# [.net] Event-raising terminology

This topic is 4909 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Maybe this is just sophistry, but it's been getting on my nerves in the MSDN documentation, because to me it doesn't make sense. Usually I just ignore it, but since I am documenting all the controls in the control library I'm writing, I want to make sure my documentation makes sense. Taking as an example Control's Size/SizeChanged/OnSizeChanged, MSDN states:
Size (Public Property)           - Gets or sets the height and width of the control.
SizeChanged (Public Event)       - Occurs when the Size property value changes.
OnSizeChanged (protected Method) - Raises the SizeChanged event.

To me, this seems backwards. They are stating that the OnSizeChanged actually raises the event. Surely, changing the Size property raises the SizeChanged event, which calls the OnSizeChanged event handler (i.e. the method that reacts to/handles the event that has been raised). Semantically, I guess you could say that the handler 'razes' the event (as in consumes it) but thats a stretch at best. So anyway, could anyone explain to me why MSDN documentation writes in this seemingly illogical manner, and put my mind at rest. As it is, it's bad enough reading it in the MSDN docs, let alone possibly having to document my controls that way - especially when it's screaming out to me that it's the wrong way round. Yours, Ann-Marie

##### Share on other sites
The idea is that whenever the size changes internally, whether by modification of the Size property or perhaps through some other way, the control will call OnSizeChanged. That in turn raises the SizeChanged event, which notifies anyone who has added an event handler for SizeChanged.

Size is modified -> OnSizeChanged -> SizeChanged raised

Things could've been implemented your way, but that would've required registering self event handlers during control construction, which is slightly less efficient than the current implementation.

##### Share on other sites
Quote:
 Original post by ArchimageSurely, changing the Size property raises the SizeChanged event, which calls the OnSizeChanged event handler (i.e. the method that reacts to/handles the event that has been raised).

Surely not. The On*Changed method is used to actually raise the event, not handle it. Most implementations will look like this:
protected virtual void OnSizeChanged(object sender, EventArgs args){   if (OnSizeChanged != null)      OnSizeChange(this, EventArgs.Empty);}

There are two main reasons for having this method instead of raising the event wherever you need to:

* You avoid code duplication of those two lines
* It allows derived classes to deal with this event without actually hooking up an event handler:

protected override void OnSizeChanged(object sender, EventArgs args){   base.OnSizeChanged(sender, args);   // code to deal with the change of size here}

##### Share on other sites
Thank you both for your quick and concise explanations. Although my vision of how it worked would be feasible, I can see that it would add additional handler-registration, and duplicated code (as well as possibly limiting some of the convenience). Now the documentation won't scream at me as looking wrong every time I see it (and I can write my own documentation without a wrong assumption).

Thank you again,

Yours,

Ann-Marie

##### Share on other sites
Not sure if it was mentioned, but,

it may make more sense to know that an event can only be called by the owner class.
Ie,

event EventHandler MyEvent;

can only be called like so:

if (MyEvent!=null)
MyEvent(this,EventArgs.Empty);

by the class that the even is defined within. This is because an event is often publically visible, and you don't want external classes (or even subclasses) calling it. The base implementation of OnSizeChanged will call this event, so when you override OnSizeChanged yourself, if you still want the event to be called, then you say base.OnSizeChanged().

I realise I'm reiterating Arild Fines here, but I thought the first point may mean it makes more sesne.

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 15
• 11
• 9
• 9
• 43
• ### Forum Statistics

• Total Topics
634131
• Total Posts
3015719
×