Overriding (?) a function in a control.

[Mufasa]

I'm going to create a server control in ASP.Net/C# that reacts to a couple
of buttons. Thing is - I want to have the functions there for the buttons so
if somebody doesn't program the command for it, it will still work - just
not do anything. The norm will be that there will be code for the button
though.

How do I go about doing this? Is this overloading?

TIA - Jeff.

 

[Alberto Poblacion]

I'm going to create a server control in ASP.Net/C# that reacts to a couple
of buttons. Thing is - I want to have the functions there for the buttons
so if somebody doesn't program the command for it, it will still work -
just not do anything. The norm will be that there will be code for the
button though.

How do I go about doing this? Is this overloading?

You could fire an event when either button is clicked. If the event is
not hooked by the client code, you will know in your server control because
the event delegate contains null, so you can provide a default behavior when
this is the case (or simply not do anything if that is what you want by
default).

 

[Mufasa]

Thanks for the info. Could you point somewhere with an example. I guess I
understand the concept but I don't know how to implement it.

TIA - Jeff.

 

[Alberto Poblacion]

Thanks for the info. Could you point somewhere with an example. I guess I
understand the concept but I don't know how to implement it.

For example, imagine that your server control has some code like this to
implement the event:

public delegate void MyButtonClickedEventHandler(object sender,
MyButtonClickedEventArgs e);
public event MyButtonClickedEventHandler MyButtonClicked;

void IPostBackEventHandler.RaisePostBackEvent(string eventArgument)
{
if (this.MyButtonClicked != null)
this.MyButtonClicked(this, new
MyButtonClickedEventArgs(eventArgument));
}


Observe the place where a check is done to see if the client has connected
to the event: if (this.MyButtonClicked != null)...

Here you can add an "else" and provide default behavior in case the client
has not connected a routine to the event. Otherwise, if the user wants to
add some code to process the click of the button, they just need to create
the event routine and connect it to the MyButtonClicked event of your
control, just like you would connect to any other event in any other
control.

 

[Peter Duniho]

Small comment...

[...]
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