c＃从另一个类中的另一个静态事件引发事件

Question

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?

Answer 1

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.

Answer 2

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.