By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,760 Members | 1,585 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,760 IT Pros & Developers. It's quick & easy.

RaiseEvent

P: n/a
hi all.
in vb.net i can write RaiseEvent.
can i do it in C# also?
how?
thanks - shachar.

Nov 16 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Say you have an event

public event EventHandler Click;

event handlers for the EventHandler type events have the signature
void MyHandler( object sender, EventArgs e);

so at the point you wanted to raise the event you write call the event like a method ...

Click( this, EventArgs.Empty); // "this" is the sender and the event args is empty in this case

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<1b****************************@phx.gbl>

hi all.
in vb.net i can write RaiseEvent.
can i do it in C# also?
how?
thanks - shachar.
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.768 / Virus Database: 515 - Release Date: 22/09/2004

[microsoft.public.dotnet.languages.csharp]
Nov 16 '05 #2

P: n/a
Just to add, when creating general classes the pattern is to indirect the
call to the event with a protected virtual OnClick method that checks for
nullability (no one listening) of the Click event before raising it. This
helps derived classes to raise click event themeselves as they cannot raise
the event directly. Making OnClick virtual also allows the derived class to
intercept the event to do some work prior to any listeners recieving it:

public event EventHandler Click;
protected virtual void OnClick()
{
if( this.Click != null )
{
this.Click( this, EventArgs.Empty );
}
}

Events are raised by calling OnClick.
Regards
Lee

"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:ez*************@TK2MSFTNGP11.phx.gbl...
Say you have an event

public event EventHandler Click;

event handlers for the EventHandler type events have the signature
void MyHandler( object sender, EventArgs e);

so at the point you wanted to raise the event you write call the event like a method ...
Click( this, EventArgs.Empty); // "this" is the sender and the event args is empty in this case
Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<1b****************************@phx.gbl>
hi all.
in vb.net i can write RaiseEvent.
can i do it in C# also?
how?
thanks - shachar.
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.768 / Virus Database: 515 - Release Date: 22/09/2004

[microsoft.public.dotnet.languages.csharp]

Nov 16 '05 #3

P: n/a
There is a problem with this (one that there has been a debate about
recently). When you perform the check like this:

if( this.Click != null )
{
this.Click( this, EventArgs.Empty );
}

There could be a race condition between the checking of Click against
null, and the call to Click. In order to get around this, you should really
do this:

// Store the reference to the delegate.
EventHandler e = this.Click;

// Perform the check.
if (e != null)
// Fire.
e(this, EventArgs.Empty);

However, JIT can get in the way here. It can see that the local
variable is really just a reference to Click, and optimize it away, leaving
you with the original condition (checking Click directly, which you don't
want). You could get around this (forcing the copy to be performed) by
passing Click to a method that will invoke it (the reference will be copied
on the stack, and it will not be optimized away.

HOWEVER (yes, again), JIT can strike again, inlining the method into the
local code, and then optimizing the parameter out (it's just another value
on the call stack now, like a variable).

If that method is defined as virtual though, it can not be inlined, and
the reference will be copied, and nothing will happen. It won't work in
this case because the reference is never copied to a variable that is not
optimized away.

In order to get around this, there are a few solutions. One is to
assign a default delegate to the event that points to empty code. This way,
you never have to check against null, since you always know there will be
one event listener. The anonymous methods introduced in v2.0 makes this
easy, by allowing the following:

// The Click event.
public event EventHandler Click = delegate{};

Another way to get around this is to define the event as volatile (it
will be allowed in .NET 2.0).

A third way would be to have a standard method makes the calls to fire
the delegate (dynamically), which would circumvent the optimizations (by
being virtual, or ultimately calling something which is virtual that passes
the delegate in as well as the parameters).

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Lee Alexander" <lee@NoSpamPlease_Digita.com> wrote in message
news:u6**************@TK2MSFTNGP10.phx.gbl...
Just to add, when creating general classes the pattern is to indirect the
call to the event with a protected virtual OnClick method that checks for
nullability (no one listening) of the Click event before raising it. This
helps derived classes to raise click event themeselves as they cannot
raise
the event directly. Making OnClick virtual also allows the derived class
to
intercept the event to do some work prior to any listeners recieving it:

public event EventHandler Click;
protected virtual void OnClick()
{
if( this.Click != null )
{
this.Click( this, EventArgs.Empty );
}
}

Events are raised by calling OnClick.
Regards
Lee

"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:ez*************@TK2MSFTNGP11.phx.gbl...
Say you have an event

public event EventHandler Click;

event handlers for the EventHandler type events have the signature
void MyHandler( object sender, EventArgs e);

so at the point you wanted to raise the event you write call the event

like a method ...

Click( this, EventArgs.Empty); // "this" is the sender and the event
args

is empty in this case

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<1b****************************@phx.gbl>

hi all.
in vb.net i can write RaiseEvent.
can i do it in C# also?
how?
thanks - shachar.
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.768 / Virus Database: 515 - Release Date: 22/09/2004

[microsoft.public.dotnet.languages.csharp]


Nov 16 '05 #4

P: n/a
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
There is a problem with this (one that there has been a debate about
recently). When you perform the check like this:

if( this.Click != null )
{
this.Click( this, EventArgs.Empty );
}

There could be a race condition between the checking of Click against
null, and the call to Click. In order to get around this, you should really
do this:
<snip>
A third way would be to have a standard method makes the calls to fire
the delegate (dynamically), which would circumvent the optimizations (by
being virtual, or ultimately calling something which is virtual that passes
the delegate in as well as the parameters).


The fourth way - the way I prefer - is to use a lock (and preferrbly
not "this") as I show in
http://www.pobox.com/~skeet/csharp/t...ckchoice.shtml

Using the no-op handler is a nice solution too.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #5

P: n/a
Jon,

A lock would definitely work, but from a maintinence ease-of-use
standpoint, it is a nightmare. The no-op handler is a better solution from
this perspective.

I think that the solution to have a static method (which in turn calls a
virtual method ultimately on an instance) is the best solution. It requires
minimal work on the part of the programmer, and it just works. All the
logic is encapsulated there.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
There is a problem with this (one that there has been a debate about
recently). When you perform the check like this:

if( this.Click != null )
{
this.Click( this, EventArgs.Empty );
}

There could be a race condition between the checking of Click against
null, and the call to Click. In order to get around this, you should
really
do this:


<snip>
A third way would be to have a standard method makes the calls to
fire
the delegate (dynamically), which would circumvent the optimizations (by
being virtual, or ultimately calling something which is virtual that
passes
the delegate in as well as the parameters).


The fourth way - the way I prefer - is to use a lock (and preferrbly
not "this") as I show in
http://www.pobox.com/~skeet/csharp/t...ckchoice.shtml

Using the no-op handler is a nice solution too.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #6

P: n/a
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
A lock would definitely work, but from a maintinence ease-of-use
standpoint, it is a nightmare. The no-op handler is a better solution from
this perspective.
I don't see it as a nightmare at all - you just put it in a single
method, and call that method when you want to raise the event. Often
you'd want that method anyway, so that it could be overridden. (Look at
all the OnXXX methods in the Windows Forms classes.)
I think that the solution to have a static method (which in turn
calls a virtual method ultimately on an instance) is the best
solution. It requires minimal work on the part of the programmer, and
it just works. All the logic is encapsulated there.


I disagree. It's not completely obvious to the reader how it solves the
threading problem, because it relies on what the JIT is able to do.
It's not totally beyond the bounds of possibility that there might be a
JIT which *does* inline virtual methods and then removes the
optimisation if the method is ever overridden, just like Hotspot does
for Java.

I suspect we'll have to agree to disagree though :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.