Question

I’m writing my custom events in C++/CLI (I pretty much only care about the add/remove methods) as such:

    event EventHandler<XyzEventArgs^> ^Xyz     {         void add(EventHandler<XyzEventArgs^> ^handler);         void remove(EventHandler<XyzEventArgs^> ^handler);         void raise(Object ^sender, XyzEventArgs ^e);     } 

Everything works great, but when I look at Intellisense under C#, it shows an ugly-looking public raise_Xyz method.

Any ideas on how to hide that without making my events private?

Any help greatly appreciated.

EDIT:

I was able to eliminate the public raise_Xyz methods by marking them with a different visibility modifier (internal in my case). This pretty much means that the events cannot be raised from outside of the class. That’s fine with me. I have noticed, however, that even simple events

public: event EventHandler ^XXX; 

generate raise_XXX methods and they are protected. Is there any way of preventing that from happening?

Answer 1

note that this is true for the ECMA-372 specification. c# 4 changes the event mechanism scaffold created by the compiler so the C++/CLI ones may also change

Because the events are handled by the compiler generating the relevant scaffold (or allowing you to do your own scaffold for them) there will, by necessity, be a bunch of methods generated to do this.

C++/CLI differs from most other .Net languages in that it’s event sugar allows sub classes to raise events declared on the base class.

    public ref class Class1     {     public:         event EventHandler^ MyEvent;     };      public ref class Class2 : Class1     {     public:         void Foo()         {             this->MyEvent(this, gcnew System::EventArgs());         }     }; 

This compiles (and runs) just fine. compare to c# equivalent

    public class Class1     {         public event EventHandler MyEvent;     }      public class Class2 : Class1     {         public void Foo()         {         base.MyEvent(this, new System::EventArgs());         }     } 

which will refuse to compile saying:

The event ‘Class1.MyEvent’ can only appear on the left hand side of += or -= (except when used from within the type ‘Class1’)

For C++/CLI to do this it must expose the raise_Xxx method as protected. Exposing the underlying delegate field which maintains the event by default would be dangerous as well as disallowing the flexibility of a class to implement events its own way without an automatic delegate backing field.

If you don’t want subclasses to be able to do this (or see it) then making it internal is an effective solution for code which is outside the assembly.

note that the C++ CLI spec defines the naming convention for the event scaffolding

18.2.2 Member names reserved for events

For an event E (§18.5), the following names are reserved:

• add_E
• remove_E
• raise_E

So this is not something which can be changed