Custom Web Controls Demystified, Part 2 (Cont.)
Events are one area where composite controls shine in terms of simplicity and ease to follow. Implementation of the IPostBackEventHandler and IPostBackDataHandler interfaces is not necessary. This is not to say that they cannot be used in special circumstances, but such are beyond the scope of this article and are usually the case in very complex Web controls. You’ve noticed so far that the design of a composite control is very straightforward and very similar to how you would render controls dynamically on a Web Form using its code-behind class. Events are no exception. You need to wire an event handler from the btnSend control’s Click event to a method within your EmailContact control, much like you would wire such an event from a control to a Web Form’s method. You’re going to do this wiring in the constructor of the control. Since you’re initializing your child controls at the class level, you don’t want to wire events in the CreateChildControls method, otherwise multiple event handlers can end up wired every time the method gets called. Some control developers choose to simply declare their child controls at the class level and then initialize them in the CreateChildControls method. In this case, the event handlers can be wired in that method since the controls are getting reinitialized on every hit, and the event handlers are getting cleared. I’ve seen it both ways and choose to do it the way I am demonstrating here because I am trying to limit the actual object instantiations, which is where the performance hit of composite controls resides.
In VB.NET:Public Sub New()
AddHandler btnSend.Click, _
In C#:public EmailContact()
This code should not be strange to you, as it simply wires the Click event of the btnSend control to the btnSend_Click method. Incidentally, the SetDefaults method you see here simply initializes some of the child control properties. The btnSend_Click event is a place where you can give your control a lot of versatility. I’ll show you an abridged version of it and then I’ll describe what’s going on.
In VB.NET:Protected Sub btnSend_Click( _
ByVal sender As Object, ByVal e As EventArgs)
If Me.AutoHandle) Then
Dim o_EventArgs As CancelEventArgs = _
RaiseEvent BeforeEmailSend(Me, _
If Not o_EventArgs.Cancel Then
' Send email here
Me, New EventArgs)
RaiseEvent SendButtonClick( _
Me, New EventArgs)
In C#:protected void btnSend_Click(
object sender, EventArgs e)
CancelEventArgs o_EventArgs =
if (this.BeforeEmailSend != null)
// Send email here
if (this.AfterEmailSend != null)
if (this.SendButtonClick != null)
The btnSend_Click method gets called within the EmailContact control when the Send button is clicked. Remember that the btnSend control raises its event to its container; in this case that is your EmailContact control, not a Web Form. It is in this method that you are going to handle e-mail-sending functionality, but you’re going to do it in a way that will make this control usable in many other situations. As you see in the code, I’m checking a property called AutoHandle to determine if you’re going to handle sending an e-mail or simply raise an event (SendButtonClick). You may run into the situation where a developer wants to use this control strictly for visual purposes. If you go through all the properties of the finished control in the downloadable code, you’ll see that I expose the value of every text field in the control whether or not you chose to show it (remember the ShowSubject property). A Web site may want to handle special e-mailing circumstances within their Web Forms and simply use your control for the data entry portion; afterward raising an event informing the form that it’s free to perform whatever tasks it sees fit. By simply toggling a property, AutoHandle, you can provide the choice of automatically handling e-mailing or manually handling it. To provide even further functionality, I have added two more events to raise in the case the developer has chosen to have your control handle e-mailing automatically, BeforeEmailSend and AfterEmailSend. Obviously these events allow the control to inform the Web Form when it’s about to send an e-mail and when it’s done. The BeforeEmailSend event is defined using the CancelEventHandler delegate so that the Web Form that receives the event can set the Cancel property in the arguments to true. As you can see, this is then checked in the code to determine whether to continue with the e-mail sending functionality.
I’ve left out the details of the e-mail sending code as well as error handling code in the interest of space, but the downloadable code contains everything. The final code also defines the AfterEmailSend event with an event handler delegate that returns a success/failure indicator. I also want to note that the control includes properties you can use to set the mail server, destination e-mail, or other field values to assist the control in its communication functionality.
Although I’ve left out a lot of extra functionality of this control that is in the downloadable code, you’re pretty much done with the EmailContact composite Web control. The three controls I’ve discussed in this article demonstrate the three types of ASP.NET Web controls and demonstrate many of the technologies involved in creating them; many but not all. There are other technologies in the .NET Framework that you can use when designing and developing custom Web controls and though explaining them in full is beyond this article, I will briefly summarize them for you.