What is the syntax for declaring an event as an argument of a function?

How do declare FireEvent(...) so I can use it in foo()
With previous beta versions, I can just do this FireEvent(EventHandler^ e), but with beta2 compiler, I get C3918.

Thanks,
hdp.

// class that defines events
ref class EventSource {
public:
    event EventHandler^ OnEvent1;
    event EventHandler^ OnEvent2;

    void FireEvent(...)
    {
         ....
    }

    void foo()
    {
         FireEvent(OnEvent1);
         FireEvent(OnEvent2);
    }
};

Answer this question

What is the syntax for declaring an event as an argument of a function?

Spenceee
Have you reported it as a bug If not, please do so.

http://lab.msdn.microsoft.com/productfeedback/
t.g.
What is the message for that compiler error That does look like the correct syntax.
BabuReddyh

C#:

    event EventHandler a;
    event EventHandler b;
    void Fire( EventHandler e)
    {
      if (e != null)
        e(this, new System.EventArgs());
    }

    void Bar()
    {
      Fire(a);
      Fire(b);
    }

Works also in VS2002/2003

Greetings
Jochen
Derek Diamond
hdp203 wrote:
Is there a workaround until it's fixed I have alot of these calls in my solution.
Thanks.

For now, I replaced the function with a macro and it seems to works.
ch
I recall that bug. This is by design in the new syntax - Managed Extensions should still work correctly.

In your scenario, it might work better to use delegates as data member in the class, instead of full events, like so:

delegate void EventHandler(int);

ref class EventSource {
public:
    EventHandler^ OnEvent1;
    EventHandler^ OnEvent2;

    void FireEvent(EventHandler^ e)
    {
      e(10);    //fire the event
    }

    void foo()
    {
         FireEvent(OnEvent1);
         FireEvent(OnEvent2);
    }
};

A trivial event (like event EventHandler^ OnEvent1;) is not a datamember, it's an abstraction of a delegate behind the event. Managed Extensions didn't make that distinction, but I think it's an important one.
mrboldt
Can you please tell me (or point me to where I can find more information on) the differences between declaring something "event EventHandler^ e;" and "EventHandler^ e;" What I can/cannot do with the two

thanks, hdp.
Tarun_Patel
I'd say that qualifies this as a C++/CLI bug in beta 2!
FabioPoroli

First of all: The example works also in VC2002/2003:
    __event EventHandler *a;
    __event EventHandler *b;
    void Fire(EventHandler *e)
    {
      if (e != NULL)
        e(this, __gc new System::EventArgs());
    }
    void Bar()
    {
      Fire(a);
      Fire(b);
    }

And it does not compile (and therefor also not work) in VC2005B2 when compiled with /clrldsyntax.

The second is: In C++/CLI you do not need to check if the event is "null"! You can just call it:
      a(this, gcnew System::EventArgs());

But you are right: The following does not work:
    event EventHandler ^a;
    event EventHandler ^b;
    void Fire(EventHandler ^e)
    {
      if (e != nullptr)
        e(this, gcnew System::EventArgs());
    }
    void Bar()
    {
      //Fire(a); // generates: "usage requires 'A::Class1::a' to be a data member"
      //Fire(b);
      a(this, gcnew System::EventArgs());
      b(this, gcnew System::EventArgs());
    }

So this might be a bug... but I did not read the C++/CLI spec...

---
Greetings
Jochen
Archonn
Hi hdp203!
Yes, I did this morning.

To make it more helpfull, here is the link to the bug-report:
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=ac4f8e6b-c5eb-4ad0-9585-2fd0542a06aa
```
-- 
Greetings
 Jochen
 
  My blog about Win32 and .NET
  http://blog.kalmbachnet.de/
```
WastingBody
The bug was closed as "by design", which is a cop-out answer if ther ever was one. An event IS a data member, just a hidden one.

Care to open a new feedback as a suggestion that this wrong descision be re-visited
AnnyJacky
Hi,

Can't pass the event EventHandler^ to a parameter coz its declared as an event but not a "Data Member delegate"... (I assume that EventHandler^ is a .net Delegate since you need a delegate when you create an event)

eg.

delegate void Del();
Del^ myEvent1;
event Del^ myEvent2;

void Fire(Del^){};

//Can do this
Fire(myEvent1);
//Causes error C3918
Fire(myEvent2);

What are you trying to achieve anyway

cheers,

Paul June A. Domag
Angusl
Yes, I did this morning.

hdp.
texlnghorn
Is there a workaround until it's fixed I have alot of these calls in my solution.
Thanks.
double eagle
This sounds like a non-feature to me, although it could be deliberate (or a bug).

Under the covers, an event IsA delegate, so I would expect (and want) it to be possible to treat the event as a delegate. Passing the event to a central 'event raising' function is not an unreasonable thing to want to do, IMO.

Does C# allow passing an event to a function that takes the corresponding delegate type
What is the syntax for declaring an event as an argument of a function?

Answer this question