Re: Consuming your own events.

In case of framework/library code, I would favor consistency over
correctness. Maybe your solution has some problems attached to it too.
When you find out about it, what will happen? A fourth pattern? Being
that the official guideline and the vast majority of .NET code use the
OnXXX pattern, I will go that way.

Also, as others have pointed out, most of the time I override the
OnXXX method is because I want to control the execution order (very
useful in ASP.NET). It is also useful to patch buggy controls which
raise events when they should not.

If something smells fishy to me, it's WPF and the hoops it needs to go
through to raise events. Looks like leaky implementation ...

On a related note, binding, control validation and many other things
works differently in WPF, Winforms and ASP.NET. Would it be nice that
we get one "meta" model that can be used in all of them. Sure! Will we
get that one day? I doubt it.

Sébastien

On 1/30/08, Sebastien Lambla <[email protected]> wrote:
> Most developers have to use multiple frameworks in their day-to-day jobs.
>
> The fact that multiple frameworks use the OnXxx naming convention
> differently introduces consistency issues that directly impact the
> robustness of your code, especially when you build frameworks for others.
>
> When something smells badly, you can try and take the point of view that one
> of the implementation choices is the right one, apply it, and expect
> developers to understand and accept your view of the pattern, or you can
> avoid it like the plague and define better semantics to solve the problem
> once and for all.
>
> --
> SerialSeb
> http://serialseb.blogspot.com
>
>
> > -----Original Message-----
> > From: Discussion of development on the .NET platform using any managed
> > language [mailto:[email protected]] On Behalf Of Sébastien
> > Lorion
> > Sent: 30 January 2008 12:41
> > To: [email protected]
> > Subject: Re: [DOTNET-CLR] Consuming your own events.
> >
> > Well, I understand your scenario better now, but ... this is (up to
> > now) specific to WPF and it is not the first time that the one making
> > guidelines is breaking them .... *cough* binding *cough*.
> >
> > Why would this apply to, say, ObservableCollection<T> ?
> >
> > Sébastien
> >
> > On 1/30/08, Sebastien Lambla <[email protected]> wrote:
> > > I'm talking about using attached events that your type is not an
> > owner of.
> > > For example
> > >
> > > public event MouseButtonEventHandler MouseDown
> > > {
> > >     add
> > >     {
> > >         this.AddHandler(Mouse.MouseDownEvent, value, false);
> > >     }
> > >     remove
> > >     {
> > >         this.RemoveHandler(Mouse.MouseDownEvent, value);
> > >     }
> > > }
> > >
> > >
> > > Now let's see what the OnMouseDown method is.
> > >
> > > protected virtual void OnMouseDown(MouseButtonEventArgs e)
> > > {
> > > }
> > >
> > > Sparing you with the nasty details:
> > > EventManager.RegisterClassHandler(typeof(UIElement),
> > Mouse.MouseDownEvent,
> > > new MouseButtonEventHandler(UIElement.OnMouseDownThunk), true);
> > >
> > >
> > > So the next generation UI framework uses OnXxx for event handling
> > (not
> > > raising!). Raising itself uses the RaiseEvent method.
> > >
> > > This conflicts with the guidelines that have been discussed, conflict
> > less
> > > with the ones i've just explained. Because of that, I advise against
> > using
> > > the On notation, to prevent the confusion introduced by different
> > > frameworks...
> > >
> > > --
> > > SerialSeb
> > > http://serialseb.blogspot.com
> > >
> > >
> > > > -----Original Message-----
> > > > From: Discussion of development on the .NET platform using any
> > managed
> > > > language [mailto:[email protected]] On Behalf Of
> > Sébastien
> > > > Lorion
> > > > Sent: 30 January 2008 11:45
> > > > To: [email protected]
> > > > Subject: Re: [DOTNET-CLR] Consuming your own events.
> > > >
> > > > On 1/30/08, Sebastien Lambla <[email protected]> wrote:
> > > > >
> > > > > When you start, like in WPF, using different property stores for
> > your
> > > > > events, the problem becomes even worse (and it's that problem
> > that
> > > > has
> > > > > triggered my move to this new pattern).
> > > >
> > > >
> > > > Could you elaborate on this bit, I am not sure I follow you. I
> > think
> > > > you mean to use a hashtable to associate events to their delegate
> > > > instead of default
> > > > storage (ie one field by event) ? If so, how is it affected by the
> > > > OnXXX pattern ?
> > > >
> > > > ===================================
> > > > This list is hosted by DevelopMentor(R)  http://www.develop.com
> > > >
> > > > View archives and manage your subscription(s) at
> > > > http://discuss.develop.com
> > >
> > > ===================================
> > > This list is hosted by DevelopMentor(R)  http://www.develop.com
> > >
> > > View archives and manage your subscription(s) at
> > http://discuss.develop.com
> > >
> >
> >
> > --
> > Sébastien
> > www.sebastienlorion.com
> >
> > ===================================
> > This list is hosted by DevelopMentor(R)  http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>


-- 
Sébastien
www.sebastienlorion.com

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

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