Event and event handler

Question

0.00/5 (No votes)

See more:

What exactly is an event and an event handler?

In this C# line

C#

context.BeginRequest += context_BeginRequest;

Where is the event and the event handler? How do you call the left part and and right part of the +=?

Posted 23-Oct-14 15:43pm

Bastien Vandamme

Add a Solution

Comments

BillWoodruff 24-Oct-14 0:09am

Do keep in mind that learning to transform being irritated with realizing you don't know how to understand/use/achieve something in programming ... yet ... into a relatively calm ... or even positively excited ... state of mind ... is: something that almost all of us have to develop through experience, through learning to separate frustration with doing and knowing from any "inner judgement" that: because we can't quite grasp whatever it is we are somehow deficient, stupid, not talented, etc.

For most of us, that is a life's work: learning how to learn. And, one of the wonderfully challenging things about programming is that you almost always need, these days, to keep actively self-educating, and learning new skills, and tools, because the pace of innovation in hardware, and software, is so rapid.

Look at this CP survey:

http://www.codeproject.com/Surveys/1688/Whats-the-best-part-about-being-a-software-develop.aspx

The highest percentage of votes cast by survey takers (programmers) in voting on the statement: "What's the best part about being a software developer?" was: "There's always something new to learn" !

In my opinion technical learning is a skill that can be always developed further. For any one individual what may be helpful may vary: one person may learn best by intense "marathons" of single-minded focus; other people (like me), learn best through alternating top-down learning with bottom-up coding to solve problems I set for myself.

Some people post here with specific questions to get answers, and be "on their way:" that's fine. Other people post here for assistance with learning to program, or help with identifying where they are stuck with a specific programming error, or even to try and make progress in being able to conceptualize an idea they have that they can't quite translate into a UI and code: that's fine too.

The great advantage of being in a team with other people at varying levels of skill, including those far above your own, is that you get a chance, through observing others, to understand what may work best for you in learning, and improving ... not to mention getting where and how you are confused ... at any given moment ... identified clearly. What is identified clearly can, imho, be worked on much more skilfully than what what one cannot even conceptualize.

... end of sermon ... :) If only I could "live up to" my own words !

Bastien Vandamme 24-Oct-14 1:04am

I agree with this. By the way the survey doesn't explain what kind of new think people like to learn. Will you invest time to learn something if I say you this think will be obsolete soon? Learning science like mathematics, algorithms, statistics basic and common concept of OOP, SOA, AOP and so is not the same as learning engineering like instructions of a brand x product build by a company.

There is a difference between, for instance, SQL and an SQL server or C# and .NET or a specific library of .NET.

The survey should also ask what's the worst part about being a software developer?

BillWoodruff 24-Oct-14 1:32am

I think when you try to think about how any specific individual would have motivation, or be enthusiastic, about learning any new technology you would need to have a lot of information about that individual, about their character, their cognitive style, their social/cultural/socio-economic status in their culture.

But, fortunately, every time you learn some technology deeply, in my opinion: you increase your general ability to learn, your confidence in future mastery given a new challenge. And, interestingly, there's some good evidence from the study of the anthropology of education in cultural context that indicates that "discontinuities" are uniquely valuable. I'd like to see a programmer who is a one-trick pony, like a master of C#, learn a radically different approach, like declarative programming (F#, for example).

That said, I think there is a certain type of higher-level learning (mathematics, formal computer science) abstracted from any specific computer language that will pay off across a broad-range of new learning challenges in programming. I regret I have not had as much of that as I would like since I jumped into programming at age forty, and I admire people like Sergey who, obviously, can think on a much higher-level of abstraction about programming ... even if I can't fully understand what he writes :)

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-10-23T16:01:00

Solution 2

So far, it's pretty simple: context.BeginRequest is the event instance. This is the class which has invocation list. The '+=' operation adds the handler (actually, a delegate instance), this that invocation list. In your case, the handler is context_BeginRequest. Interestingly, event instances are immutable, so, in fact, '+=' operator creates a brand new instance of the event instance and adds all handlers already found in the invocation list before the operation, adds a new handler are returns that new event instance. This way, the member context.BeginRequestNaturally, which is the reference object, looses its referential identity. Eventually, old event instance object, as it becomes inaccessible, will be garbage-collected. This is done to improve multithreading properties of event instances.

You can read about it, as well as some other interesting facts, in my article, the section 4.1 On the Nature of Delegate Instance.

Now, as right part is just the method, you can call it method the same way as any other method. The object on left is the event instance. For event instances, there is no such concept as "call". It can be invoked, so all elements of the invocation list will be called. That's why there is no a "call". Moreover, the invocation (BeginRequest.Invoke(/*...*/) cannot be done anywhere except the declared type. If the source code of this type is yours, you can invoke the event. This is the important fool-proof feature of .NET, to guard naive developers from invoking an event instance when it is not needed. You can read about it in my past answer: UserControl custom event[^].

—SA

Posted 23-Oct-14 16:01pm

Sergey Alexandrovich Kryukov

Comments

BillWoodruff 23-Oct-14 22:20pm

+5 I hope the OP can digest this level of content. Aside: I consider it a weakness of C# that an EventHandler can be called directly, rather than ONLY being "raised" in the usual manner through 'On......(someValidObject, someValidEventArgTypeInstance):

// legal !
btnSomeButton_Click(null, null);

I've seen many (bright people) beginning students of C# have difficulty "getting" Events, and Delegates, not to mention the fact that 'Action and 'Func are Delegate Types.

What if ... C# required a special form of declaration for an event handler method:

private EventHandlerMethod SomeButton_Click(object sender, EventArgs e) { ... }

Well :) ... yes, that's quite a fantasy, and I imagine Anders might get a chuckle reading it !

Sergey Alexandrovich Kryukov 23-Oct-14 22:32pm

Thank you, Bill.

You see, too much protection would be pointless. Let's assume that a handler is a special construct. It is almost so, if you, say, allow only anonymous handlers:

someObject.someEvent += (sender, eventArgs) =>
{ // what's inside the '{}' cannot called from anywhere except someEvent.Invoke
   //...
}

Very good. But nothing prevents from something like

someObject.someEvent += (sender, eventArgs) =>
{ // what's inside the '{}' cannot called from anywhere except someEvent.Invoke
    RealHandler(); // one place to call
}

//...

RealHandler(); // ... another call

And where is your protection? By definition, RealHandler() cannot be anything different from a regular method.
And nothing can protect a fool from writing any stupid thing like

A[0] = 0;
A[1] = 1;
A[2] = 2;
//... I only today saw something like that in Q&A

The really good practice would be using only anonymous handlers in cases where some code should only be called. This is not always the case.

—SA

BillWoodruff 23-Oct-14 22:56pm

Indeed, I really like the fact that a Lambda Expression is much more of a "private" thing, in the sense that it cannot be removed from the invocation list.

My "fantasy" only pertained to how the language itself might constrain the syntax of EventHandlers written as named methods; I wasn't thinking of any change/limitation to the nature of the multi-cast Event Type itself.

The fact that you can "get away with" writing a valid EventHandler like this:

private EventHandler someButton_Click(object sender, EventArgs e)
{
MessageBox.Show("strange indeed ?");
// no return statement: compile error !
return null;
}

... well ... this is the kind of thing that bright students come up with, as they struggle with Delegates/Events/EventHandlers in C#.

The technique I use if I want to create an Event that can only be subscribed to once (an Event "singleton," as it were) is to use an 'Action or 'Func defined as 'private in a Class, and assigned to only in the CTor of the Class.

Sergey Alexandrovich Kryukov 23-Oct-14 23:11pm

That is pretty strange, return a delegate from a method which can be used as an event handler (as I can only know from context). Normal delegate type used in events is void. How could it be used? I can imagine it, but I don't see your point.

One important thing: events subscription is a way to create memory leaks.
In fact, I also use the techniques when an event handlers are never removed. I have serious arguments for such technique. I face arguments saying that unsubscribing is the way to avoid memory leaks, but I disagree. As to "only in constructor of the class" (which class, though?) would be a too big limitation. Imagine the classes with many events. To many constructors or too many constructor parameters is a bad thing. For an event instance, there is nothing better than making them public/internal members; this what they are designed for. Having initializing them in constructor defeats the purpose of events, reducing the technique the the technique of using "regular" delegate instances. That's why event is more restrictive construct than the delegate instance; it is designed to be a directly exposed member. And the protection is: no calls, no assignments, only adding/removing handlers. If I designed it, I would allow removing handlers, for some, it would be easier; and there is nothing fundamentally bad with removing handlers.
—SA

BillWoodruff 23-Oct-14 23:47pm

I think there are times that the C# Event/Delegate facility is great as-is in terms of inherent functionality, and other times ... when the programmer, perhaps, wants more privacy/encapsulation/restriction of functionality ... more difficult to work with than it (ideally) should be.

But, I do see understanding the mechanism/syntax is complex, and bewildering for many people. Perhaps you are familiar with the rather "famous" brief analogy on Delegates by Chris Sells:

https://www.sellsbrothers.com/writing/delegates.htm

I find that very few of the students I've had can make any sense out of that; yet, that's held up as a shining example of explanation all over the web in the C#-verse (or, it was several years ago, anyhow).

Here's the kind of pattern I use when I want a "singleton" EventHandler:

   // in some other Class/Form/NameSpace, etc.
   private Action<string> NotifyTextEntered { set; get; }

   // restrict to one Notify function instance
   public void setNotifyTextEntered(Action<string> theNotifiyFunc)
   {
      if (NotifyTextEntered != null) return;

      NotifyTextEntered = theNotifiyFunc;
   }

// the notification function might be invoked like this:

    private void textBox1_KeyUp(object sender, KeyEventArgs e)
    {
      if (e.KeyCode == Keys.Enter || e.KeyCode == Keys.Return)
      {
        if(NotifyTextEntered != null) NotifyTextEntered(textBox1.Text);
      }
    }

Then, naturally, the whatever that creates the instance of the Class/Form that contains this code injects a Func like so:

   someClassOrObject.setNotifyTextEntered(s => MessageBox.Show(s));
   someClassOrObject.setNotifyTextEntered(s => MessageBox.Show("will never be called ... but will not throw error in this implementation"));

Sergey Alexandrovich Kryukov 24-Oct-14 1:55am

As I understand, you hide the event instance textBox1.KeyUp, by not directly exposing the reference to textBox1. Is it so?

But then you expose the delegate instance. You kind of wrap event behavior (which you cannot change), in the delegate instance behavior. But why? Delegate instance give the user more freedom (can set to null, can multicast, can invoke from outside). What are you restricting?

Note that you call it "singleton handler", but it's not a singleton. This is because you can multicast the delegate instance itself, by calling public void setNotifyTextEntered(Action<string> theNotifiyFunc) with appropriate instance of theNotifiyFunc. (If you don't see, how to multicast, I can explain it.) This way, you allow much more than with event instance. You can completely replace the delegate instance, say, create it from scratch, make it null again, etc.

So, what's the point?

—SA

BillWoodruff · Accepted Answer · 2014-10-23T15:58:00

Solution 1

You need to do at least a minimum of research, and thinking for yourself, before you ask other people to explain fundamental concepts in .NET and C# Object-Oriented-Development to you ... as if you are not surrounded by all the resources you need on the internet.

Start with this excellent CodeProject article: [^].

Alternate studying with experimenting with putting some Controls, like a Button, a TextBox, on a Windows Forms, and create basic Event Handlers, for example, for 'Click, or 'TextChanged, using the Property Browser (F4).

Study this tutorial on MSDN: [^].

As you alternate study and experimentation, think about what in your "real world" daily life might correspond to an Event, and an EventHandler: an alarm clock going off; your telephone ringing; a smoke alarm ?

When you are comfortable creating EventHandlers for Control events in C#, then move on to learning how to create your own Event, and understanding what a Delegate is, and how Delegates in .NET implement multi-casting: the notification of all Event "subscribers."

And, think about the fact that: if an Event has "subscribers," and subscribers can be added, and deleted, then there must be something that "maintains" a list of the current subscribers. In .NET the term for this list of things-to-be-notified is called the "invocation list:" and the special functions += and -= add, and remove, a subscriber to the Event. In C# you have very limited access to this invocation list (other languages offer different types of access).

And, as you have specific questions, preferably involving code you have written yourself: come back here and ask them.

Posted 23-Oct-14 15:58pm

BillWoodruff

Updated 23-Oct-14 16:04pm

v2

Comments

Sergey Alexandrovich Kryukov 23-Oct-14 22:07pm

In principle, you answered, my 5.
However, the problem is: events is the field when MSDN documentation is frustrating. It creates so many illusions in the developers.
One of the myths (remember you posts about event "ceremonies"?) is totally redundant new operator for creating a delegate instance using the method name. (And extremely bad auto-generated code supports such myths.)
I still did not find time to participate in that thread, but I have a lot to tell. Probably, you did not least all "ceremonies" and mix "ceremonies" with recommendations and rules, but I generally agree with you. Some of the posts on that threads are also based on incomplete understanding of this topic.

That's why I decided to write a section in my article to clarify things, which are not only poorly explained in MSDN, but also not easy to explain.

Please see my answer.

—SA

BillWoodruff 23-Oct-14 22:21pm

I will read the (new ?) section of your article with interest.

Sergey Alexandrovich Kryukov 23-Oct-14 22:39pm

Well, of course you could read more, spend more time, write some research code and do investigation using the debugger and decompilation. It could tell you a lot. Besides, the CRL standard (ECMA, freely available), is more detailed. But not everyone is qualified and patient enough do conduct such research, which is not so difficult, but pretty sophisticated.

So, of course, part of your question makes sense, because, as I say, MSDN documentation on this topic is neither clear nor complete.

From the other hand, your first question, about what is event and what is instance is elementary, you could always read about it.

—SA

BillWoodruff 23-Oct-14 22:42pm

It appears that an attitude problem is part of what is keeping you from getting busy learning. Every minute you spend telling yourself "it is not clear," or, "it is difficult," is a minute you have wasted. Every time you feel "entitled" to be angry at people you imagine/think are not trying to help you, is a small piece of your life thrown away.

Sergey Alexandrovich Kryukov 23-Oct-14 23:12pm

Golden words!
—SA

BillWoodruff 23-Oct-14 23:04pm

There goes another small piece of your life.

If you deal with your attitude problem, then you will be able to distinguish between short responses that essentially say "go away" ... which do occur here, unfortunately ... with carefully thought-out responses, like mine (to you) in this thread, that refer you to specific resources carefully selected for their value based on my substantial experience teaching people from other cultures (over fourteen years of my adult life in Asia, the last ten continuously in Asia), as well as my own culture, programming.

Thanks to the internet, resources for every aspect of .NET / C# programming are available in every major Asian language, as well as English.

Trying to play the "culture card" is just a form of self-pity.

Sergey Alexandrovich Kryukov 23-Oct-14 23:34pm

You see, everyone here wants only the good for you.

Complaining is only useful when you have a chance to make people acting in better way. But then you have to convince people, which is never easy; much harder than just asking a question.

Seriously, by complaining on Internet difficulty, you cannot convince people like myself, who learned most of the things when Internet did not even exist for us, and literature was scarce. Other people took a lot from Internet from the very beginning; and you cannot convince them, too. Why? Because some of such people started with Internet also having problem with the language, but learned written language mostly by practicing reading and writing foreign language just working with Internet. I am serious, I know such people. Some of them cannot even speak that language, but can read and write. And they also learned a lot of technology. They won't be impressed with your complain, just because they learned how efficient could be the active use of Internet. Even when people say something that you understand as "go away", they hope that you go into some work, which is simply more efficient than asking any small question and waiting for answers; and nothing guarantees you that you got a good answer. (But I already told you that your question makes sense, in contrast to majority (unfortunately) of questions here. If your question was pointless, you would not get anything except "go away", but you got — I think — two pretty reasonable answer posts.)

So, you should better consider "do search on Google" and yet another advice, pretty practical, not as "go away". If I thought that nothing except Google or MSDN is really needed, I would not answer at all — I would only comment "what's wrong with reading original MSDN documentation?". After all, if something else would require a more detailed answer, that member would explain what was not clear in that documentation in a reply comment, that would give me some matter for further explanations and ultimately posting a detailed answer. It just saves time. People either really go away (unfortunately, some are not ready even for getting help, no matter how good) or provide extra detail on what exactly is a problem, and get help. How do you think, which sort of behavior would be the behavior of a looser? (Again, with your question, it's all fine. I just explained the motivation for "go and do the search" comments. They do make a lot of sense.)

One more aspect of this. Harder is easier. If you got some knowledge by your own hard work, get to the roots of things, this can become real knowledge. You go slower but arrive sooner. :-)

—SA