We Keep Coding

How is an event raised in C#?

My understanding about events in C# for a console application:
create a delegate that has the same signature as the event handler method in the subscriber class.
declare an event based on this delegate
raise the event
My understanding of this step is: it is simply an wrapper function where parameters are passed to the event to invoke the event handler functions pointed to by the event.
So raising the event is just invoking the wrapper function in the publish class.
Now when I create a very simple Windows form application, I am not able to apply this general concept.
Consider a WinForms application with just one button.
// registering statement
Button1.Click += new EventHandler (this.button1_click)
I can identify the first step. It is the pre-defined System.EventHandler delegate.
Click event for the button is also pre-defined. No problem with that.
event raising step : here I fail to make the connection between a console application and an Windows application.
Where is the code kept that actually RAISES the event for a WinForms application? We don't seem to have to code it.
I understand click event is raised when someone "clicks" on the button, but how is that realized in the C# code for WinForms application?
How does the compiler "just" knows that a Click event for a button means someone clicking on a button and therefore an event should be raised?
How is click event raised? How are the parameters passed to the event?

The Control class has protected function called WndProc, when the OS needs to tell the program something it generates a Message object and passes it in to the WndProc function.
That WndProc function then looks at the message and sees what kind of message it is, if it is the "mouse left button up" message it runs the the OnClick method with the correct parameters parsed out of the Message object that was passed in to WndProc.
That OnClick method is the thing that raises the event to the subscriber.
From the soruce of .NET:
The entry point of WndProc
It detecting the message type
It parsing and calling the OnClick method
It raising the Click event

Your understanding is a bit backwards. I think this is why you have issues.
You are not creating a delegate that has the same signature as the event handler method in the subscriber class.
What you are doing is declaring what a function to which to delegate execution will look like. Here is the signature for EventHandler:
public delegate void EventHandler(object sender, EventArgs e)
So, if you want a function to be able to handle delegation of the event, it must follow that signature.
Now, the class that will delegate execution to subscribers needs a reference to those functions so it can call them when the event takes place. That is why you implement an event property. It follows then that the Button class must expose this property for you to be able to "hook" your delegates:
public event EventHandler Click
(Notice this is inherited from Control)
When you register an "event handler":
Button1.Click += new EventHandler (this.button1_click)
You are essentially saying that you want this.button1_click(object sender, EventArgs e) to fire whenever the Click event is raised by the Button1 instance.
The Button1 instance will internally decide when to fire the event at which point it will use the event property to delegate execution to the subscribed functions. It will call them with the above mentioned parameters where sender will most likely be the instance itself and the EventArgs class will give you additional information about the conditions that raised the event. The property is also usually implemented to add additional checks (like if there is anything to call in the first place).
As you can see, the code that actually raises the click is internal to the implementation of the Button (or its inheritance chain). It obviously involves mouse tracking and what not, which is the benefit of using the controls by the way, unless you want to write all that detection stuff from scratch.

RaiseEvent PreviewMouseDown

How does one go about raising an event for PreviewMouseDown. I can successfully do this for MouseClick events... but falling short on the preview variation. The goal is the automate PreviewMouseDown and then PreviewMouseUp only when needed.
Cheers.

Not sure what you mean by "automate PreviewMouseDown" but PreviewXXX routed events in WPF are tunneled down the control automatically (from top of the visual tree) and then it calls the XXX event which gets bubbled up.
There is no way you can 'just' call PreviewXX event. Though you can handle them separtely by attaching to the right event.

Getting all the attached event handlers for a WPF control

I am developing an application where I assign the events for the button dynamically. Now the thing is that I wish to get all the events for the button click event as I wish to remove the previous handlers.
I tried setting the event handler to null like:
Button.Click += null;
However I received a runtime exception that null cannot be assigned.
I wish to know the events which are already attached to it so that I can remove those events.
Can anybody help me in achieving this?

You cannot assign events - only attach (+=) and remove (-=) operations are available for clients.
Since += and -= are the only operations that are permitted on an event outside the type that declares the event, external code can add and remove handlers for an event, but cannot in any other way obtain or modify the underlying list of event handlers.

A nice pattern is to have an Action removeAll declared somewhere, so you can do:
button.Click += handler
removeAll += () => button.Click -= handler
That way you've only got one variable to keep track of, and you can clear everything just by calling removeAll(), rather than keeping track of all your handlers individually and having to call -= on each of them. It's especially convenient if you've got multiple subclasses of EventHandler to deal with, since otherwise you'd have to keep track of them with multiple lists.

You can't do that (fortunately. Just imagine, that some external code removes your event handler, and your code just stops working in silent manner).
(Reflection isn't an option here, because event implementation may be differ from type to type). Usually, if you want to remove all event handlers this way, this means design error.

Prism CompositePresentationEvent fires twice

In my infrastructure i publish a event
this.eventAggregator.GetEvent<ReportAddedEvent>().Publish(report);
the report is a object
In my controller i subscribe to this event
this.eventAggregator.GetEvent<ReportAddedEvent>().Subscribe(this.OnReportAdded);
My problem is that the event fires twice. There is no other place in the entire code where the event is published so im certain that the event is not fired somewhere else and i can see it only fires once.
Anyone have a suggestion or have a solution to problem or knows where the problem lies.

I think the problem is that the code
this.eventAggregator.GetEvent<ReportAddedEvent>().Subscribe(this.OnReportAdded);
to subscribe to the ReportAddedEvent is executed two times.
You should check (by using a debugger and a breakpoint on the line) if it executes more than once.

Events Firing Unexpectedly

Can you write code to tell an event not to fire? Sometimes in my applications events fire unexpectedly. I know this is a broad question, but it must have happened to others out there.

You could put an if-statement in your event handler around all the code or you could dynamically detach and reattach the event handlers from outside the event handler, if necessary.
But really, events don't just fire without reason. You probably have something else going on. Maybe you can explain more what the situation is?

There is no standard way to suppress an "unexpected" event. But you could remove all of the event handlers. This is rather drastic, but would be equivalent to suppressing the event.
Alternatively you could add code to the event handlers to do nothing when the event is fired unexpectedly. This assumes you can define "unexpected".
Rather than suppress an event, a better approach is to remove/suppress whatever is that's causing the event to fire.