I recently attended a interview in C# where i was asked a question about Events and delegates in C#
The person asked me when a event say button gets clicked, which gets called first event or delegate?
Does the delegate calls the event or the event calls delegate?
Can we have a event without a delegate in c#?
The person asked me when a event say button gets clicked, which gets called first: the event or the delegate?
When you open a door, which gets opened first: the door or the doorknob?
Huh?
That question doesn't make any sense. You open a door with a doorknob, but you don't open a doorknob.
What does it mean to "call" an event? Events aren't things that you call. Events are things that you raise. Raising an event is identical with calling the delegate.
Does the delegate calls the event or the event calls delegate?
Does the door open the doorknob, or does the doorknob open the door?
Again, the question doesn't make sense. A doorknob is not something that can be "opened", and the doorknob does not open the door -- you open the door, by holding the doorknob.
Does the delegate call the event? No; events are not things that can be "called". Does the event call the delegate? No, the code that is raising the event calls the delegate.
Can we have a event without a delegate in c#?
Yes, in the sense that the delegate reference associated with an event can be a null reference. But every event is associated with a delegate type, and somehow has associated with it a reference to a delegate.
The whole set of questions indicates to me that the questioner does not have a very good understanding of the relationship between events and delegates. A good way to think about it is that an event is just a property that contains a reference to a multicast delegate. Whereas a property has special methods that get and set the value of the property, an event has special methods that add and remove delegates to the multicast delegate.
Events are a concept which utilize delegates as a means to call methods that have subscribed to them.
Events themselves are not called. When a piece of code raises an event, it will call each of the subscribed methods by invoking the delegates.
Events are raised, delegates are called. So when the button is clicked, a buttonClick event is raised, meaning that each delegate subscribed to the event will be called, according to the subscription order.
An event is simply a code construct implemented in .NET as a multi-cast delegate.
When an event is "raised" (which can only be done by code in the same class as the event; event raising must happen within "protected" scope), the delegates are invoked one at a time, in a synchronous fashion but not necessarily in any deterministic order. The event IS the delegate, so when the event is raised for a button being clicked, the delegates are invoked by the runtime, which has received the Windows message that the user clicked on the GUI area for the button.
The statements "the event is raised" and "the delegates are invoked" are equivalent statements; it's like asking "which comes first, the chicken or the gallus domesticus?".
Now, events often cascade, especially when we're talking about UI. There is a MouseUp event, invoked when the mouse button is released, which can fire one or more other events such as MouseClick, MouseDoubleClick, DragDrop, etc. You may not attach a handler to the MouseUp event, but there is built-in logic behind the scenes of MouseUp to raise the MouseClick event which you DO handle. So, in this sense, you could say that the MouseUp event "comes first" and calls the MouseClick handler delegate.
This page bubbled up on top of Google results, so below is something you might find useful if you also land here. Multi-cast delegates ARE called (see MSDN) in deterministic order on one thread, in the order of assignment. This assignment will involve an array of some sort, and it would be illogical for the indices to fill up out of order.
public partial class Form1 : Form
{
ob<Control>ob1;
ob<Control>ob2;
ob<Control>ob3;
public Form1()
{
InitializeComponent();
ob<Control>.setup(button1);
ob1 = new ob<Control>(1, true);
ob2 = new ob<Control>(2, false);
ob3 = new ob<Control>(3, false);
}
public class ob<T> where T : Control
{
int ndx;
Boolean isSentinel;
static Boolean dontdostuff;
static T c;
public static void setup(T c) {ob<T>.c = c;}//an argument less from constructor, useful for many objects (more likely to be menuitems)
public ob(int ndx, Boolean isSentinel)
{
this.ndx = ndx;
this.isSentinel = isSentinel;
c.Click += new EventHandler(click);
}
void click(object sender, EventArgs e)
{
if( isSentinel)
{
if (MessageBox.Show("ob" + ndx + " asks: short circuit subsequent delegate calls?", "", MessageBoxButtons.OKCancel, MessageBoxIcon.Question) == DialogResult.OK)
{
dontdostuff = true;
return;
}
else
{
dontdostuff = false;
}
}
else
{
if( dontdostuff) return;
}
MessageBox.Show("ob" + ndx + " doing stuff in order of handler addition", "", MessageBoxButtons.OK, MessageBoxIcon.Information);
}
}
Related
I have a program that attaches a listener to an object every time the window switches, and then calls a delegate when an event occurs on this window.
The problem is that the code assigns a new delegate every time a window is switched to, meaning one window could have multiple delegates called for one event.
To prevent this I would like to be able to un register a delegate from within the delegate function.
For example:
void OnWindowChange(CustomClass newWindow){
newWindow.OnEvent += delegate {
Console.WriteLine("This event happened.");
newWindow.OnEvent -= *this delegate*;
};
}
I was considering not using an anonymous function, but the problem is, there are at least 10 events per window object that all need hooked. So anonymous seems to be the best (DRYist) way.
If there is a better way to go about doing this, I am open to it.
I'm not new to C#, but events is one of the most confusing topics I confront in the language.
one of the questions is: where should I assign the event handler to the event, or the question in other form: why most events are raised in the subscriber constructor? what does it mean?
like this example (taken from the book Mastering Visual C# )
public ReactorMonitor(Reactor myReactor)
{
myReactor.OnMeltdown +=
new Reactor.MeltdownHandler(DisplayMessage);
}
Raise = generate. Events are not raised in the subscriber constructor. The subscriber does not raise events at all. The event source raises/generates events, and subscribers subscribe to, receive, and handle them.
Events in c# are nothing more than function pointers, i.e. a variable that contains a pointer (or list of pointers) to a function that matches a specific signature (typically Action<object,EventArgs>). Or in the words of this MSDN article:
Delegates are like C++ function pointers but are type safe.
When you subscribe to an event, you are essentially saying "Store the address of my function. When X happens, please call it (along with any other function whose address is stored)."
Thus the code
myReactor.OnMeltdown += Meldownhandler;
can be read as
objectThatRaisesEvents.FunctionPointer = MyHandler;
Notice that MyHandler is not followed by parentheses. If it were MyHandler() that means you are invoking the function, the value of the expression MyHandler() is actually the return value of the function; MyHandler by itself doesn't invoke the function or return its value but instead returns the address of the handler itself. So the above line of code takes the address of MyHandler and stores it in a variable named FunctionPointer.
When the object that raises events invokes FunctionPointer() it is telling c# to obtain the address of the function stored in FunctionPointer and invoke it.
So it is really calling MyHandler() indirectly. Thus these two lines do exactly the same thing:
objectThatRaisesEvents.FunctionPointer();
MyHandler();
Also notice the += in your example. In c# that is the equivalent of
objectThatRaisesEvents.FunctionPointer =
objectThatRaisesEvents.FunctionPointer + MyHandler;
We typically use that syntax because there might be several handlers that subscribe to an event. += has the effect of appending our handler to the list. You could use = instead, but it would unsubscribe any existing handlers.
To answer your question-- when should you subscribe to events? That is a very broad question, but typically
In an ASP.NET web page, you'd subscribe during the Init event.
In a Windows Form, you'd subscribe in the InitializeComponent method.
There are many other contexts of course... the bottom line is you should subscribe before you need to receive notifications of occurrences of the event.
The event is one of the standard features of .NET Framework built using delegate model implementing the Observer design pattern.
https://msdn.microsoft.com/en-us/library/edzehd2t(v=vs.110).aspx
https://en.m.wikipedia.org/wiki/Observer_pattern
Where you subscribe to the event depends on the business rules, but most of the time you want to subscribe at the earliest possible moment which is usually the constructor of the class interested in the handling of the event.
When events should be raised on the other hand depends on what you are trying to communicate to the subscribers if it is a notification of the state change then you raise an event as soon as state is changed.
An event is a message sent by an object to signal the occurrence of an
action. The action could be caused by user interaction, such as a
button click, or it could be raised by some other program logic, such
as changing a property’s value.
I know this is really basic stuff but I'm struggling to wrap my mind around it.
Ok so I have a method that I want to run:
public static void DelegateTest(string testStuff)
{
for (int i = 0; i < 4; i++)
{
Console.WriteLine(testStuff);
}
}
Then, outside of the scope of this method (but within the scope of my class) I define my delegate with the same output type and input parameters as my method:
public delegate void myDelegate(string test);
I instantiate my delegate like so:
myDelegate md = new myDelegate(DelegateTest);
I can then kick off my method as many times as I like by BeginInvoking the delegate, and the methods will run side by side in separate threads.
md.BeginInvoke("Hello World", null, null);
md.BeginInvoke("Hello World Again", null, null);
md.BeginInvoke("Hello World A Third Time", null, null);
How do I now define an event and only kick off my method asynchronously when the event happens? Also, what are the limitations on what an event can be? Can more or less anything that happens on my computer be defined as an event or only certain things?
Edit: Say for example, after doing the above, I want to create an event and define this event as 'the space bar has been pressed'. Every time the space bar is pressed, this is the event happening. When the event happens, I want to start my method asynchronously, I don't want to start my method asynchronously if the space bar hasn't been pressed.
How would I go about this?
Just use Invoke rather than BeginInvoke for synchronous calls.
EDIT: as per ThePower's answer, you don't need the Invoke, you can just call your delegate as if it were a function (because it is!).
EDIT2: You are actually trying to register an event handler. For this you don't need to create your own delegate. An example for handling the KeyPress event in WinForms:
public class MyForm : Form
{
public MyForm()
{
KeyPress += OnKeyPressHandler;
}
private void OnKeyPressHandler(object sender, KeyPressEventArgs keyPressEventArgs)
{
//TODO: whatever you need to do...
}
}
If you want to use it as an event, check out the event type. There's a good example here.
Although, if you want to use your delegate...
You have already defined Asynchronous, so for Synchronous use :
md("Hello World", null, null);
md("Hello World Again", null, null);
md("Hello World A Third Time", null, null);
I'm not sure I completely understand your question. In C#, for all practical purposes, an event is a delegate, meaning that any delegate can be used as an event.
Using your example:
public delegate void MyDelegate(string test);
You can now use MyDelegate as an event in a class:
public class MyClass
{
public event MyDelegate MyEvent;
}
You can now register event handlers with MyEvent and then in the event handler you can execute any code you want. From a traditional sense, this is the only way to define events in C#.
Another option to consider is using a publish/subscribe pattern such as an EventAggregator. This pattern doesn't typically rely on delegates and instead relies on an aggregator object to notify all subscribers of a published event. In this scenario, the event can really be any object that contains the information expected by the subscribers.
Following on from this post - what are the disadvantages when using the -= then += approach suggested when I only ever want one handler event to fire?
_value.PropertyChanged -= _handlerMethod;
_value.PropertyChanged += _handlerMethod;
This doesn't guarantee that there is only one handler fired.
Another location could, potentially, subscribe your handler to your event multiple times. In this case, you will only remove the first handler call.
By inspecting the invocation list of the event, you could guarantee this behavior, if you truly only want a single handler to be subscribed at a time.
If you really want only one handler to execute, then you may want to use a settable property of the appropriate delegate type instead of an event. Only one delegate will be stored; you can execute the delegate the same as you would the event handler.
The idea here is that the -= operator is not going to do anything if your event handler is not assigned.
I don't personally like this approach, I think you should really aim to refactor your code so that you know that the event handler is assigned only once.
The disadvantages would be:
- possibility of race condition, if your app is multithreaded and the event gets fired when the handler is not assigned
- I am also not sure what happens when you run _value.PropertyChanged -= _handlerMethod when two copies of the handler are already assigned.
- messy code - obviously its not clear from the code which class and when is listening to the event
CancelEventArgs provides a Property called Cancel that different event handlers can set to tell the object that invoked the event whether it should continue execution cancel the action.
It seems that since events are multicast delegates, a simple raise of the event might invoke two delegates. The first one sets the Cancel property to true, the second one sets the Cancel property to false. Do component/framework 'cancelable' events support these scenarios and invoke each delegate one by one, checking the cancel flag at each step? What is the best practice to raise these types of events? Is only one instance of CancelEventArgs passed to each delegate? Are separate instances used?
A little experiment quickly shows that they use 1 instance of Cancel (probably of the EventArgs object).
That makes it a bit of a gamble, with the outcome depending on the order in which the Eventhandlers were attached.
In the particular case of the CancelEventArgs I think the correct pattern would be to set Cancel to true or leave it alone, so the order shouldn't matter.
Tested:
public static void Main() {
Event += (sender, e) => e.Cancel = true;
Event += (sender, e) => e.Cancel = false;
Event += (sender, e) => e.Cancel = true;
var args = new CancelEventArgs();
Event(null, args);
WL(args.Cancel);
}
static event EventHandler<CancelEventArgs> Event;
The order of attached event handlers does matter.
Generally speaking, events with non-immutable event args and multicast delegates should not used together, but the .NET framework uses such events very extensively.