Develop Reference

Event Enhancement

I am trying to figure out away to reduce how many lines our event handlers take. What is the best way to integrate the add {} and remove {}, so I don't have to keep repeating it every time I make a new event.
public delegate void ErrorEventHandler(System.Object sender);
protected ErrorEventHandler ErrorEvent;
public event ErrorEventHandler Error
{
add
{
ErrorEvent = (ErrorEventHandler)System.Delegate.Combine(ErrorEvent, value);
}
remove
{
ErrorEvent = (ErrorEventHandler)System.Delegate.Remove(ErrorEvent, value);
}
}
Thanks to #madreflection the code looks like this now
public delegate void ErrorEventHandler(System.Object sender);
public event ErrorEventHandler Error;
protected virtual void OnError(object sender) => Error?.Invoke(sender);

That is an exceedingly verbose event definition.
The += and -= operators are shorthand for Delegate.Combine and Delegate.Remove, plus you could put the add and remove accessors each on a single line. That would save you some typing and a few lines.
add { ErrorEvent += value; }
Since you're not using a handler collection (e.g. the Events property in System.ComponentModel.Component), there's really no need to implement the add and remove accessors yourself.
The backing field shouldn't be protected. The class that implements the event should control how it's used.
Each event can be reduced to two lines (three if you're defining a delegate type for each event but you shouldn't have to do that):
public event ErrorEventHandler Error;
protected virtual void OnError(object sender) => Error?.Invoke(sender);
The first line is an automatically implemented event. It creates a private backing field for the event and all references to the event within the class use that field directly. It also creates a public event member that can be used by consumers to subscribe to the event. That includes add/remove logic identical to what you have.
The OnError method ("On" + event name) enables derived classes to fire the event without having to use the backing field (since it's private) and encapsulates the null-checking logic. It's protected virtual so that deriving classes can override it and insert logic (such as logging) before calling the base implementation. Thanks to #Markus Safar for pointing out the reason.

How to subscribe to events fired from any collection element in C#?

I have made the following Dictionary, and I would like to be able to subscribe to the event fired from any of its' elements, in order to know which dictionary elements' properties were changed.
Here is my class:
public class BlockInput : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public void NotifyPropertyChanged(string PropertyName)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(PropertyName));
}
private int _value;
public int Value
{
get
{
return _value;
}
set
{
_value = Value;
NotifyPropertyChanged("Value");
}
}
}
I create a concurrent dictionary like the following:
public ConcurrentDictionary<string, BlockInput> Inputs;
How would this be achieved, in order for me to find every time that one of the BlockInput values were changed/event for each element fired?
Thanks for your time.

I don't believe you have another way than manually subscribing to all events yourself:
foreach (BlockInput item in Inputs.Values) {
item.PropertyChanged += BlockInput_PropertyChanged;
}
private void BlockInput_PropertyChanged(object sender, PropertyChangedEventArgs e) {
var blockInput = sender as BlockInput; // Get the item that was changed
// Do stuff
}
You would have to subscribe to all added items and unsubscribe from removed ones as well if you plan to add or remove items from the Dictionary.

In practical use of this Interface (wich is primarily MVVM) usually this is enough. You have the GUI classes do all the plumbing work of subscribing to events. You only need to provide 3 Change Notifications:
The one of each property of BlockInput. You did that in your example code.
The one if something is added or removed from the Collection. That is what ObservableCollection<BlockInput> will take care off. It is also the only thing the OC will take care off.
The one on the property exposing the ObservableCollection<BlockInput>. The OC is notoriously bad at bulk modifications, so often you need to prepare a new instance in code, with Exposing being the last step.
If you do not have a MVVM use case, please leave a comment. I can think of 2 ways on top of manually subscribing to each Event.

c# raise event from another static event in another class

Need help calling event from another class.
I have class with declared event:
public class MxPBaseGridView : GridView
{
public event AddNewItemsToPopUpMenuEventHandler AddNewItemsToPopUpMenu;
...
}
Another class from which i need to call event has methods and "AddNewItemsToPopUpMenuEventHandler " delegate
public delegate void AddNewItemsToPopUpMenuEventHandler(PopupMenuShowingEventArgs e);
public static class GridViewUtils
{
public static void gridView_PopupMenuShowing(object sender, PopupMenuShowingEventArgs e)
{
if (e.MenuType != DevExpress.XtraGrid.Views.Grid.GridMenuType.Row)
{
if (menu != null)
{
if (sender is MxPBaseAdvBandedGridView)
{
MxPBaseAdvBandedGridView currentGrid = sender as MxPBaseAdvBandedGridView;
...
currentGrid.AddNewItemsToPopUpMenu();
if (currentGrid.AddNewItemsToPopUpMenu != null) //there i need to call event
currentGrid.AddNewItemsToPopUpMenu(e); // how you understand it doesn't work
}
so what is the right way to do the same job?

Events in C# are kind of funny things. They're very much like automatic properties, but with a private get method and a public (or whatever access you choose) set method.
Allow me to demonstrate. Let's create a hypothetical class with a hypothetical event.
class SomeObject{
public event EventHandler SomeEvent;
public void DoSomeStuff(){
OnSomeEvent(EventArgs.Empty);
)
protected virtual void OnSomeEvent(EventArgs e){
var handler = SomeEvent;
if(handler != null)
handler(this, e);
}
}
This class follows the typical pattern for a class that exposes an event. It exposes the event publicly, but has a protected virtual "On..." method that, by default, simply calls the event (if it has any subscibers). This protected virtual method not only encapsulates the logic of actually calling the event, but provides a way for derived classes to:
conveniently handle the event with less overhead,
perform some processing before or after all external subscribers receive the event,
call an entirely different event, or
suppress the event altogether.
But what is this "event" object called SomeEvent? In C#, we're familiar with fields, properties, and methods, but what exactly is an event?
Before we get into that, it helps to realize that there are really only two types of class members in C#: fields and methods. Properties and events are more or less just syntactic sugar on top of those.
A property is really either one or two methods, and a name stored in metadata that the C# compiler allows you to use to refer to one of those two methods. That is, when you define a property like this one:
public string SomeProperty{
get{return "I like pie!";}
set{
if(string.Compare(value, "pie", StringComparison.OrdinalIgnoreCase) == 0)
Console.WriteLine("Pie is yummy!");
else Console.WriteLine("\"{0}\" isn't pie!", value ?? "<null>");
}
}
the compiler writes two methods for you:
public string get_SomeProperty(){return "I like pie!";}
public void set_SomeProperty(string value){
if(string.Compare(value, "pie", StringComparison.OrdinalIgnoreCase) == 0)
Console.WriteLine("Pie is yummy!");
else Console.WriteLine("\"{0}\" isn't pie!", value ?? "<null>");
}
I don't mean this obliquely. These two methods literally become part of your compiled class along with a chunk of metadata about the property, which tells the compiler next time which methods to call when the property is read from (get) or written to (set). So when you write code like this:
var foo = someObject.SomeProperty;
someObject.SomeProperty = foo;
The compiler finds the getter and setter methods assigned to SomeProperty, and turns your code into:
string foo = someObject.get_SomeProperty();
someObject.set_SomeProperty(foo);
This is why if you define a class with a public field, but later decide to change it to a property so that you can do something interesting when it is read from or written to, you have to recompile any external assemblies that contain references to this member, because what was a field access instruction needs to become a method call instruction, instead.
Now this property was somewhat abnormal, in that it didn't rely on any backing field. Its getter returned a constant value, and its setter didn't store its value anywhere. To be clear, that's perfectly valid, but most of the time, we define properties more like this:
string someProperty;
public string SomeProperty{get{return someProperty;}set{someProperty = value;}}
This property doesn't do anything other than read and write to a field. It's pretty much the same as a public field named SomeProperty, except that you could add logic to that getter and setter at a later date, without making consumers of your class recompile. But this pattern is so common, that C# 3 added "automatic properties" to achieve the same effect:
public string SomeProperty{get;set;}
The compiler turns this into the same code as we wrote above, except that the backing field has a super secret name that only the compiler knows, so we can only refer to the property in our code, even within the class itself.
Because the backing field is inaccessible to us, while you might have read-only properties like this:
string someProperty;
public string SomeProperty{get{return someProperty;}}
you'll almost never see read-only automatic properties (the compiler lets you write them, but you'll find very little use for them):
public string SomeProperty{get;} // legal, but not very useful unless you always want SomeProperty to be null
Instead, what you'll usually see is this:
public string SomeProperty{get;private set;}
The private access modifier attached to set makes it possible for methods within the class to set the property, but the property still appears read-only outside the class.
"Now what does any of this have to do with events?" you may ask. Well, as a matter of fact, an event is very much like an automatic property. Normally, when you declare an event, the compiler generates a super secret backing field and a pair of methods. Except that the backing field isn't quite as super secret, and the pair of methods aren't "get" and "set", they're "add" and "remove". Let me demonstrate.
When you write an event like this:
public event EventHandler SomeEvent;
what the compiler writes is this:
EventHandler SomeEvent;
public void add_SomeEvent(EventHandler value){
SomeEvent = (EventHandler)Delegate.Combine(SomeEvent, value);
}
public void remove_SomeEvent(EventHandler value){
SomeEvent = (EventHandler)Delegate.Remove(SomeEvent, value);
}
It also adds some metadata glue so that later, when you write code like this:
void Awe_SomeEventHandler(object sender, EventArgs e){}
void SomeMethod(SomeObject Awe){
Awe.SomeEvent += Awe_SomeEventHandler
Awe.SomeEvent -= Awe_SomeEventHandler
}
the compiler rewrites it as (only the interesting lines):
Awe.add_SomeEvent(Awe_SomeEventHandler);
Awe.remove_SomeEvent(Awe_SomeEventHandler);
What's important to take note of here is that the only publicly accessible members related to SomeEvent are those add and remove methods, and those are called when you use the += and -= operators. The backing field, that delegate object named SomeEvent that holds the event's subscribers, is a private field that only members of the declaring class can access.
However, much like the way automatic properties are only a shortcut for writing the backing field and getter and setter by hand, you can explicitly declare your delegate and add and remove methods as well:
internal EventHandler someEvent;
public event EventHandler SomeEvent{
add{someEvent = (EventHandler)Delegate.Combine(someEvent, value);}
remove{someEvent = (EventHandler)Delegate.Remove(someEvent, value);}
}
Then, other classes within your assembly can trigger your event:
var handler = Awe.someEvent;
if(handler != null)
handler(Awe, EventArgs.Empty);
However, it's easier and more idiomatic to define your event the normal (automatic) way, and just expose a "Raise" method:
internal void RaiseSomeEvent(){OnSomeEvent(EventArgs.Empty);}
But now you hopefully understand why you have to do it this way, and what's going on in the background.

You can only invoke an event in the class where you have defined the event. What is common is to use a specific method to fire the event, which you have to add in the class where you define the event. In your case, in the class MxPBaseGridView. Add the following:
public void OnAddNewItemsToPopUpMenu(<eventargstype> e) {
var addNewItemsToPopUpMenu = AddNewItemsToPopUpMenu;
if (addNewItemsToPopUpMenu != null)
addNewItemsToPopUpMenu(this, e);
}
Note: I'm not sure what the eventargs-type is, so I've left it open.
Then you can call this method from your static method.
Note: normally I define the On... methods as private, if necessary as protected. In this case I've defined it public since you need to call it from outside your class.

what is the use of custom event arg?

Here is the code for custom event args. I am confuse about use of those and also role of those. I can not understand this property public object AddedObject { get; private set; } the code is here :
public class ObjectAddedEventArgs : EventArgs
{
public ObjectAddedEventArgs(object addedObject)
{
AddedObject = addedObject;
}
public object AddedObject { get; private set; }
}
I can not understand use of the get and set property of added object. Please explain to me.

The AddedObject property is what is called an "auto property", which simply means that the C# compiler will generate a private variable to hold the value of the property. The "get" is the mechanism which allows you to read the value of the property. The "set" is the mechanism which allows you to set the value of the property, although in this case since the set is private you aren't able to set the value. This translates to code which would look roughly like this:
private object _AddedObject;
public object AddedObject
{
get { return this._AddedObject; }
private set { this._AddedObject = value; }
}
The class itself (the ObjectAddedEventArgs class) is used to provide additional data (the AddedObject value) to an event handler which, presumably, would access that data and do something with it as part of it's response to the event.

As per Microsoft's documentation:
EventArgs is the base class for classes containing event data.
....
This class contains no event data; it is used by events that do not
pass state information to an event handler when an event is raised. If
the event handler requires state information, the application must
derive a class from this class to hold the data.
That being said, the original developer of that class intended to handle events and at the same time making the object AddedObject available to the event handler method. See the website above for a nice example.

the good thing when you declare your events like this
event EventHandler<ObjectAddedEventArgs> MyObjectAddedEvent;
you can subscribe to it in a weak manner easily
myObjectInstance.MyObjectAddedEvent += new EventHandler<ObjectAddedEventArgs>(MyObjectAddedEventMethod).MakeWeak(eh => d.MyObjectAddedEvent -= eh);
private void MyObjectAddedEventMethod(object sender, ObjectAddedEventArgseventargs)
{
//do something with the event args
}
the weak stuff you find here.

Prioritising Event Handlers

I have the following code where I am handling an event twice. However I always want to ensure that mynewclass always handles the event first and then the local event handler code fires. I understand the MyClass event should fire first as that is the one created first but because the thread and enqueuing is taking place, I think its taking too long and its doing something in myhandleeventlocal before I want it to do that. Any way I can wait for it to happen?
public MyMainClass
{
private MyMethod()
{
MyClass mynewclass = new MyClass();
mynewclass.myObject += MyHandler(myhandleventlocal);
mynewclass.loadedevent += EventHandler(loadedevent)
}
private void myhandleventlocal()
{
//do stuff
}
private void loadedevent()
{
//do some stuff
}
}
public MyClass
{
public MyObject myObject;
public event loadedevent;
public MyClass()
{
myObject = new MyObject();
myObject += MyHandler(myhandlevent);
}
private void myhandlevent(long value, string detail)
{
//Start a thread
//Enqueue value and detail
//On seperate thread dequeue value and process it
//Raise loadedevent event
}
}
UPDATE: I have updated my question and code to demonstrate the problem.

By default the event handlers are called in the order you add them, so if you always add the handlers in the order you want them to fire then it should work.
From Jon Skeet's article on events and delegates:
[...] extra delegates are both added to and removed from the end of the list [...]
Note: You can override the default behaviour of events by changing the add and remove operations on your event to specify some other behaviour. You can then keep your event handlers in a list that you manage yourself and handle the firing order based on whatever rules you like.

If you can't guarantee the order the event handlers will be added, just add the one for mynewclass and then in that code call the other code.

Since event handlers are called in the order you add them, based on the code I see in your question, you can't make mynewclass's handler be called first. The event handler that MyClass creates is always added first.
One solution would be to control priority for the event handlers. Instead of using the builtin event handler +=/-= operators, you would instead have methods for adding and removing events where you could specify ordering explicitly. That way, if a class knows it needs to handle the event first, it could ask for such. Be careful, though, because you could easily run into a situation where multiple classes are each insisting that they handle the event first.
Here is some quick and dirty code to get you started:
class MyClass {
private LinkedList<MyEventHandler> eventHandlers;
public enum Ordering { First, Last, ... };
public void AddHandler(MyEventHandler handler, Ordering order) {
switch(order) {
case Ordering.First:
eventHandlers.AddFirst(handler);
break;
// fill in other cases here...
}
}
public void RaiseEvent() {
// call handlers in order
foreach(MyEventHandler handler in eventHandlers)
eventHandler();
}
}

Referring to siride solution, you can also implement your handlers and decide the position that way. Like inverting the order (always add at the begin) or add some logic.