How to Creating a Slightly More Complex Control ?
For this example, we will create a login screen that consists of two labels, two text-box server controls, two required field-validation server controls, and a button server control. We will also expose a property or two to make it a little more versatile. After we have created a blank user control in our project, add the following.
In the code-behind, add the following code.
The first thing to notice is that a user-control class is abstract. It must be inherited to implement its functionality. This is done by the parent page, which treats the user controls as a child object. Also, notice that the class inherits from System.Web.UI.UserControl. This gives the control the internal plumbing it needs to render itself. Most of the events and properties can be specified and overridden in your code-behind. After the control declarations, we declare two global variables. These contain the values set in the public property get and set routines. Also, be aware that the sBorderColor variable is public because we are referencing this variable in the HTML using our tried and true <% %> tags.

The get and set routines set the global variables' values. The properties of the user control can either be set in the host page HTML at design-time or in the host page code-behind at runtime.

Notice how the property names exposed in the get and set routines are specified in the control declaration on the hosting page. Values can be passed in here as strings. As we will see in part 2, the internal logic may be expecting a different data type, and we will have to handle that circumstance. Also, the property names are not case-sensitive if referenced in the HTML. By setting some special attributes on the class, properties may also be set as child elements on the object. To do this, set the class attribute "ParseChildrenAttribute" equal to true. This may be useful if you have a multitude of properties to set or child controls to create at runtime. The DataGrid server control and calendar server control make good use of this.

Now we set the text-box equal to the sUsername value. The event that this fires on is the OnPreRender event. This event is part of the page life cycle (which user controls consequently share), and we are overriding it to fire our code at that time. The OnPreRender event is one of the last events that fires during the creation of a page, so we are assured that the contents of the text box will not be disturbed by typical mechanisms in the ASP.NET page life cycle. If we ran this code at the Page_Load event, the contents of our text box would not remain intact because the ViewState information would clear it out. For more information on the course of a page from creation to disposal, look at my article entitled The ASP.NET Page Life Cycle. By using this functionality, we can set the username text box if we need to, as described in the code comments above.

Setting the username property is not required at all, but it is important to thoroughly test your controls with various (or no) values set in your properties. You may get unexpected results. Placeholders are set within the code above to allow you to get the username from other sources, such as a cookie or previous login. When completed, the control could be placed on any page that requires a login. Logic could be placed in the Page_Load event that will set the control's visibility property to false if the user has the required credentials. Since the control is seen as one complete object, this is done by simply making the statement, "this.visibility = false".
Creating a Slightly More Complex Control
see control