Develop Reference

Where should events be raised?

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.

Events and Delegates Order when event is triggered

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);
}
}

Ensuring that we subscribe only once to an event

Here is my question: if I want to ensure, that a handler is subscribed only once, is it correct to subscribe in this way:
x.Event -= Handler;
x.Event += Handler;
Idea is "try unsubscribe, even if we were not subscribed", then subscribe when we are 100% not subscribed.
Is this idea correct, and if not - why? Googled it for some time, cannot seem to find the answer myself.

So long as you do that everywhere you're subscribing that handler, it should be fine. But if you subscribe 100 times and then run that code, you're still going to be left with 100 subscriptions.
(I'm assuming you're only using a single thread, by the way. There's a race condition if two threads execute that code at the same time... they could both unsubscribe an then both subscribe, leaving two active subscriptions.)

What you have will not throw any exceptions, so it will work as intended -- but it's not very clear code.
I would very much prefer a test with a boolean flag instead:
if(!subscribed) {
x.Event += Handler;
}

Should I instantiate a new delegate or not?

I just realized I can add an event handler in two ways:
Consider an event handler like so:
private void MyEventHandler()
{}
Method 1: Instantiate a new delegate
MyObject.MyEvent += new Action(MyEventHandler);
Method 2: Add event handler without instantiating a new delegate
MyObject.MyEvent += MyEventHandler;
Is there any difference in between these two implementations that should be considered?

There is no difference, the generated IL is the same. The shorter form was introduced in .net/c# 2.0 as a convenience function, although Visual Studio still does the first form on Tab Completion.
See this question for some more info.

I believe that while you can unsubscribe from the second, you'd not be able to unsubscribe from the first.
That would be a pretty important distinction. There is really nothing to be gained by wrapping it in an Action in any case.
update
Okay, I think I misunderstood what you were doing. If the event is declared as
public event Action MyEvent;
then the two subscriptions are equivalent, the second being shorthand for the first.
There are actually other ways to add event handlers:
MyObject.MyEvent += delegate { MyEventHandler(); };
MyObject.MyEvent += () => MyEventHandler();
In these cases, you would not be able to unsubscribe. In these examples, the delegates are calling the handler method, but usually when employing this method it is to avoid having to create separate handler methods -- the handler code goes right in the anonymous method.

Checking if an event handler exists

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