Re: Consuming your own events.

On Wed, 30 Jan 2008 16:20:12 +0000, Sebastien Lambla <[email protected]>
wrote:

>> So, to summarize: prefer RaiseX over OnX because RaiseX is more
>> explicit
>> that the method is meant to only raise an event.  If you use the OnX
>> pattern and only raise events from that method and overrides, you'd
>> have
>> the same thing...
>
>Prefer the raise because the intent is clearer than the On that is either
>used to raise events or to handle event notifications depending on which
>part of the .net framework you're using.
>
>If you want your observers to cancel an event, use the Xxxing / Xxxed
with a
>CancelableEventArg to cancel the raising of the second event.

That's a good one too.  This isn't documented anywhere?  I've been using
it forever so I don't remember if I read it somewhere else.


>If you want your children to cancel an event, that's a gray area. I'm not
>opposed to making RaiseXxx virtual, but it provides the possibility of
>implementing behaviour in children classes and causes the same issue of
>forgetting to call the base RaiseXxx. But there's so much you can do, and
>forgetting to call base.Raise has much stronger sematnics than base.On

It depends on what you define "cancel" is.  In the case of Xing and Xed,
if there are multiple subscribers to Xing and Xed, and one of the
subscribers cancels Xing, does that cancel calling all subsequent Xing
subcribers as well as never calling Xed?  Then, there's always the issue
of a derived class "cancelling" by not calling the super's Xing--so you've
got a blend of canceling techniques.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com