Event handlers

[Tony Johansson]

Hello!

I know it's possible to have several event handler for a single event but I
can't
see any point using several event handler for this.

I'm probably wrong so can anybody tell me what advantage it might give using
several
event handler for a single event.

//Tony

[Jon Skeet [C# MVP]]

On Aug 7, 7:40*am, "Tony Johansson" <johansson.ande [e-mail] >
wrote:

I know it's possible to have several event handler for a single event butI
can't see any point using several event handler for this.

I'm probably wrong so can anybody tell me what advantage it might give using
several event handler for a single event.

Suppose two completely separate pieces of code both want to react to a
button being clicked. One might be performing the normal user
interface interaction, and the other might be logging all UI
interaction for usability reasons. How would you do that without
multiple event handlers?

Another example: the AppDomain.Domai nUnloaded event. How can you
possibly be sure that only one piece of code will be interested in the
timing of AppDomain unloading?

Another example: Marc Gravell and I developed "Push LINQ" where data
is effectively pushed through predicates etc rather than pulled.
Handlers are registered to say they're interested in seeing data being
produced (and the "end of data" event). Using multiple event handlers
attached to the same event, you can compute several aggregates on the
same stream of data incredibly easily.

Having multiple event handlers doesn't come up *very* often, but it's
handy to be able to do it, and the way that delegates work make it
simple to achieve.

Jon

[Tony Johansson]

Hello!
If I have n event handlers will these always be called in the same sequence
as they subscribe to the event

//Tony

"Jon Skeet [C# MVP]" <sk***@pobox.co mskrev i meddelandet
news:b7******** *************** ***********@z6g 2000pre.googleg roups.com...
On Aug 7, 7:40 am, "Tony Johansson" <johansson.ande [e-mail] >
wrote:

I know it's possible to have several event handler for a single event but

I

can't see any point using several event handler for this.

I'm probably wrong so can anybody tell me what advantage it might give

using

several event handler for a single event.

Suppose two completely separate pieces of code both want to react to a
button being clicked. One might be performing the normal user
interface interaction, and the other might be logging all UI
interaction for usability reasons. How would you do that without
multiple event handlers?

Another example: the AppDomain.Domai nUnloaded event. How can you
possibly be sure that only one piece of code will be interested in the
timing of AppDomain unloading?

Another example: Marc Gravell and I developed "Push LINQ" where data
is effectively pushed through predicates etc rather than pulled.
Handlers are registered to say they're interested in seeing data being
produced (and the "end of data" event). Using multiple event handlers
attached to the same event, you can compute several aggregates on the
same stream of data incredibly easily.

Having multiple event handlers doesn't come up *very* often, but it's
handy to be able to do it, and the way that delegates work make it
simple to achieve.

Jon

[Jon Skeet [C# MVP]]

On Aug 7, 9:54*am, "Tony Johansson" <johansson.ande [e-mail] >
wrote:

If I have n event handlers will these always be called in the same sequence
as they subscribe to the event

That depends on the implementation of the event's add/remove accessors
- but with any sane implementation will use the same sequence, as
that's the natural behaviour of Delegate.Combin e/Remove.

Jon

[William Stacey [C# MVP]]

I'll have to check out your push linq. Sounds interesting.

....
Another example: Marc Gravell and I developed "Push LINQ" where data
is effectively pushed through predicates etc rather than pulled.
Handlers are registered to say they're interested in seeing data being
produced (and the "end of data" event). Using multiple event handlers
attached to the same event, you can compute several aggregates on the
same stream of data incredibly easily.
.....

[Jon Skeet [C# MVP]]

William Stacey [C# MVP] <wi************ @gmail.comwrote :

I'll have to check out your push linq. Sounds interesting.

My current best attempt to explain it is:

http://msmvps.com/blogs/jon_skeet/ar...uot-push-quot-
linq-revisited-next-attempt-at-an-explanation.asp x

Or you can just look at the code, of course:
http://pobox.com/~skeet/csharp/miscutil

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[William Stacey [C# MVP]]

Thanks. The name makes me think of a push-sql feature I have wanted before.
Something like:
from rec in db.Table1.Inser t
where rec.Name != null
select into somedelegate();

So the db will push insert events and data back to my client delegate async.
Kinda like a CCR Selector, but instead of a port/queue, the queue is the db
table. Would make apps like outlook with caching new items locally from
some time T forward kinda ~easy. I guess another way to look it would be a
generic notification system against various providers (sql, news, pop3, etc)
but with linq.

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************@m snews.microsoft .com...

William Stacey [C# MVP] <wi************ @gmail.comwrote :

>I'll have to check out your push linq. Sounds interesting.

My current best attempt to explain it is:

http://msmvps.com/blogs/jon_skeet/ar...uot-push-quot-
linq-revisited-next-attempt-at-an-explanation.asp x

Or you can just look at the code, of course:
http://pobox.com/~skeet/csharp/miscutil

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com