-3-

Writing our own Web Controls

So far, we have been exclusively using controls provided by Microsoft. Since they are web based, they are also termed as Web Controls. In this chapter, we will show you how to create your own web control. Any Web Form can be modified to become a Web Control. A Web Form that is used as a server control is termed as a user control.

a.aspx

<%@ Language="C#" %>

<%@ Register TagPrefix="vijay" TagName="sonal" Src="a1.ascx" %>

<html>

hi <br>

<vijay:sonal runat="server"/>

</body>

</html>

a1.ascx

Great ASP+ book

Output

Great ASP+ book

Nothing can be simpler than creating a user control. We first need a tag or a tag prefix to identify the control. In the previous chapter, all ASP+ controls started with the tag prefix asp:. This tag prefix was then followed by the word button or textbox. These type of words are given the nomenclature of tag names.

In the case of user controls, we initially need to register our control with ASP+. To achieve this, a directive called Register is used. It is followed by the attributes TagPrefix, TagName and Src. Register is known as a directive because it is preceded by the @ sign. TagPrefix and TagName are initialized to vijay and sonal, respectively. So, the tag usage will now be vijay:sonal. Finally, it is essential to provide the file name of the file that contains the source code of our control. To accomplish this, Src is initialized to a1.ascx.

By convention, we shall always name our source code file as a1.ascx. The big boys at Microsoft have requested the developers to standardize the file extension as ascx, but this is not mandatory. The file a1.ascx has only a single line of text i.e. Great ASP+ book. Hence, the output replaces the control tag vijay:sonal with this line. Life could not get any simpler !

a.aspx

<%@ Register TagPrefix="vijay" TagName="mukhi" Src="a1.ascx" %>

<html>

hi <br>

<vijay:mukhi id="aaa" runat="server"/>

<br>

</form>

</body>

</html>

a1.ascx

public String Color = "blue";

</script>

The color property is <%= Color %>

Output

The color property is blue

This program associates a property called Color with the control. A property can be introduced by simply adding a public variable in the ascx file, and then displaying it using <%=. Here, the public variable Color is initialized to blue. Hence, we catch sight of the colour blue in the browser. This simple act of creating a public variable, which gets converted into a property, can also be used with tags created by us. The next program illustrates this point.

a.aspx

<%@ Register TagPrefix="vijay" TagName="mukhi" Src="a1.ascx" %>

<html>

hi <br>

<vijay:mukhi id="aaa" Color="green" runat="server"/>

<br>

</form>

</body>

</html>

Output

The color property is green

The original value of the property can be overwritten in the tag. Hence, we see the value as green and not blue.

a.aspx

<%@ Register TagPrefix="vijay" TagName="mukhi" Src="a1.ascx" %>

void abc(Object s, EventArgs E)

{

aaa.Color = "red";

}

</script>

<html>

hi <br>

<vijay:mukhi id="aaa" Color="green" runat="server"/>

<br>

<asp:button text="Change " OnClick="abc" runat=server/>

</form>

</body>

</html>

Output

The color property is red

Bear in mind that there is no distinction between the properties created by us and the built-in properties of the tag. Thus, in the function abc, we can modify the value of the property Color to red. The new values override the default ones.

a.aspx

<%@ Register TagPrefix="vijay" TagName="mukhi" Src="a1.ascx" %>

void abc(Object s, EventArgs E)

{

aaa.Color = "red";

}

</script>

<html>

hi <br>

<vijay:mukhi id="aaa" Color="green" runat="server"/>

<br>

<asp:button text="Change " OnClick="abc" runat=server/>

</form>

</body>

</html>

a1.ascx

String aa = "blue";

public String Color

{

get

{

return aa;

}

set

{

aa = value;

}

</script>

The color property is <%= Color %>

We start with the output window displaying the following output:

Output

The color property is green

And after we click on the button, the output that is now displayed, is as follows:

Output

The color property is red

We have carried out numerous modifications to the file a1.ascx, but we have left the file a.aspx untouched.

The C# programming language understands properties and uses keywords/accessors like 'get' and 'set' to operate upon them. Since the language used in the ASP+ file is given as C#, this feature can easily be exploited to act upon the tag properties.

In the ascx file, the local variable aa is initialized to the value blue. On the next line, the statement commences with the word 'public' associated with the Color property and with the return value as String.

A property can either be used on the left or the right side of an = sign. If it is on the left, then it is being assigned a value. So, when we write Color="blue" in a tag, we are setting the value of the property Color to blue, which is a string. ASP+ uses the set accessor to store the value into the property. The variable aa contains the value blue. Hence, the property Color is initialized to blue.

When a property is placed on the right side of the 'equal to' sign, it will return the value contained in it. In the aspx file, <%= Color> is used to obtain the current value of the property Color. Accordingly, ASP+ calls the 'get' accessor. The only statement within 'get' is 'return aa' which will return the value stored in aa to the aspx file.

Apparently, both the techniques that used to create a property, appear identical; however,there is a subtle difference. In the first case, we are merely changing the value of a variable, whereas, in the second instance, we are calling functions.

A function can contain and execute innumerable lines of code. These statements can perform error checks and ensure that the user does not infringe on the permissible values of the property. A similar paradigm is noticeable in the highly successful Microsoft product, Visual Basic, which extensively supports the concept of properties.

a.aspx

<%@ Register TagPrefix="vijay" TagName="mukhi" Src="a1.ascx" %>

<html>

void Page_Load(Object s, EventArgs E)

{

if (Page.IsPostBack)

{

Response.Write("true a.aspx");

aa.Text = bb.Password;

}

else

Response.Write("false a.aspx");

}

</script>

<vijay:mukhi id="bb" Password="hell" runat="server"/>

</form>

<asp:Label id="aa" runat="server"/>

</body>

</html>

a1.ascx

public String Password

{

get

{

return Pass.Text;

}

set

{

Pass.Text = value;

}

</script>

<ASP:TextBox id="Pass" TextMode="Password" runat="server"/>

<ASP:Button Text="Submit" runat="server"/>

Output

false a.aspx

The file a.aspx has a custom tag called vijay:mukhi. It has an id of bb and a property called password, which has been initialized to 'hell'.

Since the label aa has no value, Page_Load does not display any text when the page is loaded. Since the file a.aspx has been requested for, from the server by writing the url as http://localhost/a.aspx, (submit button is not used), the property IsPostBack is false. Hence, the output is depicted as false.

The source code file a1.ascx has a property called password, which is declared public and which returns a String. In order to initialize and retrieve values of the property, a textbox with an id of Pass is used instead of a variable. Since the TextMode is Password, the characters that are keyed in are not visible.

Further, a button labeled as 'submit' has been added to the ascx file to take us back to the server. Therefore, an existing control can be used to hold a value.

A user control can accommodate multiple controls. The View-Source too does not spring up any surprises.

View-Source

false a.aspx

<html>

</form>

</body>

</html>

In the ascx file, the textbox was assigned the id of Pass, and the control name in a.aspx name was bb. Hence, in the HTML file generated by the server, it is termed as bb:Pass. This is done merely to maintain the sanctity of names, as the same name could have been assigned to the textbox in both the files. When we type hell in the textbox and click on the button, the output that is displayed is as follows:

Output

True a.aspx

Hell

When we click on the submit button, the file a.aspx is called. Since the button is responsible for calling the a.aspx file, the property IsPostBack is assigned a value of true. Hence, True is displayed. The label in Page_Load is initialized to the password 'hell' because our textbox contains the word 'hell'.

Had we modified this value, we would not have been in such a muddle. Instead, the label would have displayed these values too. All this happens only on the server. An ascx file can definitely contain code that is normally written in an aspx file.

a.aspx

<%@ Register TagPrefix="vijay" TagName="mukhi" Src="a1.ascx" %>

<html>

void Page_Load(Object Src, EventArgs e)

{

if (Page.IsPostBack)

Response.Write("true1");

else

Response.Write("false1");

}

</script>

<vijay:mukhi runat="server"/>

</form>

</body>

</html>

a1.ascx

void Page_Load(Object Src, EventArgs e)

{

if (Page.IsPostBack)

Response.Write("true");

else

Response.Write("false");

}

void abc(Object sender, EventArgs e)

{

Response.Write(aa.SelectedItem.Value);

}

</script>

<ASP:DropDownList AutoPostBack="true" id="aa" OnSelectedIndexChanged="abc" runat="server">

<ASP:ListItem value="business">Business</ASP:ListItem>

<ASP:ListItem value="trad_cook">Traditional Cooking</ASP:ListItem>

<ASP:ListItem value="mod_cook">Modern Cooking</ASP:ListItem>

</ASP:DropDownList>

Output

false1falsetrad_cook

Along with properties, a user control can also have events associated with it. In fact, it can contain every feature that is usually built into a tag. We can implement our own callbacks also. The above example amply validates this feature.

We have integrated a listbox in our control and associated a function abc with it. With every change in the item that is selected from the options in the listbox, abc shall be called.

Both files have a Page_Load function. It is relatively easy to verify which Page_Load function gets invoked first. This can simply be accomplished by placing a Write function with each of these functions, and verifying the output by determining the order in which they are being executed.

The output lucidly and comprehensively demonstrates that the Page_Load, which forms the part of the main file a.aspx, is summoned first, followed by the user controls. Moreover, as we keep changing the current selection, the abc function gets called repeatedly, resulting in the display of the newly selected values.