Small comment...
Alberto Poblacion wrote:
[...]
void IPostBackEventHandler.RaisePostBackEvent(string eventArgument)
{
if (this.MyButtonClicked != null)
this.MyButtonClicked(this, new
MyButtonClickedEventArgs(eventArgument));
}
IMHO, the above should read more like this:
void IPostBackEventHandler.RaisePostBackEvent(string eventArgument)
{
MyButtonClickedEventHandler handler =
this.MyButtonClicked;
if (handler != null)
{
handler(this, new MyButtonClickedEventArgs(eventArgument));
}
else
{
// implement default behavior here
}
}
This will ensure that one thread unsubscribing the event at the same
time another thread raises it won't result in a null exception.
And a minor clarification just to make the intent of this approach
clear: what Alberto is saying is that client code wouldn't subscribe to
the button click event at all; instead, the client code would subscribe
to this new event, and the control would respond to the button click by
raising this new event.
That way, the control has the opportunity to observe whether anyone is
actually subscribed to the event, allowing it to provide default
behavior if no other code is.
Now, all that said, I don't know what the implications are in ASP.NET,
but in a regular Forms application I would first approach this by
overriding the OnClick method in the control itself. There you could
replicate the event raising behavior yourself rather than calling the
base class, observing the Click event value directly and providing the
default behavior there:
protected override void OnClick(EventArgs e)
{
EventHandler handler = Click;
if (handler != null)
{
handler(this, e);
}
else
{
// implement default behavior here
}
}
That way you don't have to add an extra event to the class, and clients
can't cause trouble by still subscribing to the Click event. It does
have the downside of not calling the base OnClick method, but AFAIK all
that does is raise the event, so as long as you do that yourself, you're
fine.
Pete
