Re: Consuming your own events.

I'd like to add: I think 'event' as a word causes the confusion here. An event
as a .NET element, is raised when an event happens, when something happened,
to signal subscribers that something happened. The On<Event> methods are
usable as ways to signal derived classes using other ways than subscribing to
events (the .net element) when an event (something occurred) took place.

        FB

> > In this case the guidelines are right and sadly you are wrong =)
> > Your proposed solution isn't at all bad; but it is an even more complex
> > guideline then the one provided by MS, and even worse it is only your
> guideline =(
> > Here are a few fast comments:
> >
> > 1. the protected virtual OnTheEvent( ... ) shall only EVER be used to
raise
> > the event; no other logic.
> > If you implement other logic here, in a class designed for inheritance you
> are
> > in trouble.
>
>         Erm...
>         DataSourceControl.RaiseDataSourceChangedEvent
>
>         So much for guidelines, eh? ;)
>
>         Your reasoning is pretty flawed. The On<Event> methods can also be
> seen as methods which are called WHEN the event is raised or WHEN something
> happens (which doesn't necessarily have to be resulting in the raise of an
> event!)
>
>         Your reasoning seems to be based on what's defined in Winforms.
That's
> all great, but .NET code is more than just winforms. I for example use
> On<SomeEvent> methods to make classes extensible so derived classes can tap
in
> the pipeline when an event OCCURS in the base class (and which perhaps
results
> in the raise of an event for subscribers). This thus means that
On<SomeEvent>
> methods are called by the method which raises the event, they in itself
aren't
> doing anything.
>
> > 2. Cancelable events are just a hack, remember that an event is a
multicast
> > delegate. Using OnTheEvent( ... ) you can control if the event is raised.
> Sure
> > you can get the invocation list and call the clients one at a time; but
how
> do
> > you handle the case
> >  where a client further down the list cancels the operation??? Do you
> > compensate for it??? If so how???
> > Building a Before and After could work, but then you could as well Plain
Old
> > Callback interfaces (java/COM style) and really get down and dirty =)
>
>         Do you really understand what cancelable events are all about?
They're
> not events which should be raised AFTER a fact, they're events which are
> raised BEFORE something is about to happen. E.g. an object is about to be
> removed from a collection. Right before the removal, you raise an OnDeleting
> event. All subscribers can check if that removal is allowed. If not, they
> cancel the event. But 'event' here isn't the OnDeleting event. 'event' here
is
> the 'removal'.
>
>         So cancelable events are definitely not a hack, they're a great way
to
> create a disconnected system where subscribers can tap into a pipeline
without
> much effort.
>
> > 4. Using base classes are always pretty brittle; It is just simply very
very
> > very hard to design and implement a class correctly for inheritance.
>
>         No it's not that hard. Operating a hammer is also not that hard, but
> if you smash something with it it might break, so be careful.
>
>                 FB
>
> ===================================
> This list is hosted by DevelopMentor.  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com

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

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