HomeASP.NET ASP.NET Custom Server Controls: Breaking t...
ASP.NET Custom Server Controls: Breaking the Secrets of Rendering
If you are confused about the rendering methodologies of a custom control in ASP.NET, you can simply master it from all of the secrets I introduce in this article.
In my previous article, I already introduced you to creating your own TextBox control with cool features, without even deriving it from an existing ASP.NET TextBox control. I concentrated only on getting out my own TextBox, and not much on rendering. This article should give you insightful information about the rendering methodologies available in ASP.NET custom control development.
“Control” and “WebControl” class
To develop any custom control we generally design a class which gets derived from either of the following two classes:
System.Web.UI.Control
System.Web.UI.WebControls.WebControl
The System.Web.UI.Control provides only the basic functionality to make our custom control participate in the page frame work. The System.Web.UI.WebControls.WebControl is already derived from the System.Web.UI.Control class and provides support for additional properties such as font, height, width, and so on.
The rendering methodology between both classes is quite different from several aspects. But, one should note that both of them have the “render” method implemented internally (of course we can override them when necessary). But the lifecycle of a custom control depends upon the derivation from its parent class (either of “Control” or “WebControl” classes). This is where a control developer can get confused.
First of all, we need to decide which parent class is necessary for our custom control to be derived from. We need to make sure that we can even achieve the same output when dealing with any of those two parent classes. But, here the idea is to find the additional freebies we can get from the “WebControl” class.
If our custom control needs to implement all the types of common features like width, height, font, backcolor, forecolor, and so on, it is better to work with “WebControl.” If we want to take complete control over your custom control (including the normal features of the “WebControl” class), we need to consider the “Control” class. Once your custom control gets derived from the “Control” class, none of the features of the “WebControl” class will be available to you. You need to implement all of them by yourself.
These two classes are quite different from each other when rendering their lifecycles. Let us now go the secrets of rendering from both “Control” and “WebControl” classes.
The “Control” class mainly concentrates on the following methods to render:
RenderControl
Render
RenderChildren
Actually, any beginner would know only the “Render” method, but not the rest! Breaking the secret, actually, the ASP.NET page framework first executes the “RenderControl” method. This method in turn calls the “Render” method. Finally the “Render” method calls “RenderChildren.” In fact, the ASP.NET page framework would never call the “Render” or “RenderChildren” methods directly!
Let us further break into the secrets of their implementation internally. Internally within the ASP.NET framework, the “RenderControl” has been implemented something like this:
Public void RenderControl(HtmlTextWriter Writer)
{
If (visible)
Render (Writer);
}
Now, I think you grasp some idea. The “Render” method gets executed by the “RenderControl” method if and only if the control has its “visible” property set to “true.” In general, it is unnecessary to work with the above method.
Coming to the “Render” method, the internal implementation would be something like this:
The above code fragment is very clear and I hope that I need not explain much about it. But, if your control doesn’t have any child controls, you need not place “RenderChildren” any more. If you have any child controls, generally that should be placed at the bottom.
Coming to the “RenderChildren” method, the internal implementation would be something like this:
The above method executes the “RenderControl” method of every child control present within our custom control. If this method is overridden by us and if we don’t include the above “for” loop, none of our child controls would get displayed!
Of course, there exists another way to stop the rendering of child controls. The following code fragment ensures that our custom control doesn’t have any child controls to display:
Until now we have seen the rendering available only at the“Control” class. Now let us break the secrets of the “WebControl” class. In my previous articles, I always used only the “render” method to emit the HTML (related to the control). There exists a few more alternative methods (of course most flexible as well) to deal with this. Let us now look into some of them.
The “render” method exists in every control. Internally within the ASP.NET framework, it has been defined something like this (unless we override it):
Now, if we don’t want to consider just “render,” then we can forget completely about it and work on the other three methods, namely “RenderBeginTag,” “RenderContents” and “RenderEndTag.” “RenderBeginTag” should be generally implemented with all the opening tags of the control (together with their attributes). “RenderContents” generally contains the information which is required to be displayed (even child control information) within the same control. Finally “RenderEndTag” should be implemented with all the closing tags which were opened in “RenderBeginTag.”
Do you think the other three methods, namely “RenderBeginTag”, “RenderContents” and “RenderEndTag” can be taken for granted, without having any pre-processing? You are wrong. Each of them (except “RenderEndTag”) still require their own implementations internally within the ASP.NET framework.
The next section deals with those methods in detail.
There is something more we need to understand about “RenderBeginTag.” Internally within the ASP.NET framework, the method has been defined something like this (unless we override it):
Public virtual void RenderBeginTag(HtmlTextWriter Writer)
{
AddAttributestoRender(writer);
HtmlTextWriterTag tagKey = TagKey;
If(tagKey != HtmlTextWriterTag.Unknown)
Writer.RenderBeginTag(tagKey);
Else
Writer.RenderBeginTag(this.tagName);
}
The “RenderBeginTag” calls another method, the “AddAttributestoRender” method, to deal with all types of “attributes” related to only the opening tags. The “TagKey” corresponds to the default HTML tag corresponding to the web control. If we implement our own tags within the “RenderBegintag” method, we can simply forget about the “TagKey” issue. If you still want to know how to implement “TagKey“, the following is a sample (but generally not very much required):
Protected override HtmlTextWriterTag TagKey
{
Get
{
Return HtmlTextWriterTag.Input;
}
}
Now that we have learned about “RenderBeginTag,” let us proceed to “RenderContents.” Internally within the ASP.NET framework, “RenderContents” has been implemented something like this:
The statement “Base.Render(Writer)” must be issued at the bottom, if and only if you have some child controls to be rendered, exactly in the same hierarchy of this control’s lifecycle. This statement would indeed call the “Render” method of each and every child control which exists as part of this control recursively. If you don’t have any child controls for your control, you need not include the statement.
As I already explained above, it is the first method within “RenderBeginTag,” which gets executed to add respective attributes to the opening tags of the control. Internally within the ASP.NET framework, it has been defined something like this:
It is always a good practice to have the statement “Base.AddAttributesToRender(Writer)” as the first statement within the above method. Never remove it (unless you have a reason to do so). There also exists one more secret behind it.
During the design time of VS.NET, you may be moving the control (or adjusting its size, or so on) to your favourite location (or even changing some of its properties). All that information (say CSS) would be remembered and written back to our control using this statement. If you forget this statement, your control works in a floating manner at the left-top of the web page (without having any design time attributes set).
Guidelines for beginners
The following are some of the guidelines, which may help you in developing ASP.NET custom controls:
Even though I gave explanations for almost every method which participates in rendering, you should not try to implement all of them unnecessarily. Make a note that the ASP.NET framework is always optimized with its default implementations.
When you start developing any new custom control, you will come across some funny outputs of your control. The best way to debug is to open the HTML source at the browser level and check the HTML rendered to the client (or browser) by your control. This way, it helps you to gain a faster understanding of what the control did for you.
Special care must be taken when you develop composite controls (nested controls).
Try to follow the naming convention of events and delegates very properly (when you try to implement your own events to your control).
Never consider or confirm that “something” happens automatically. Try to know the concept behind it and go in depth to the scenario of what is happening. Never take anything for granted. This would give a chance for unknown problems (or bugs) to crop up in the future.
Any comments, suggestions, bugs, errors, feedback, and so forth are highly appreciated at jag_chat@yahoo.com.
ASP.NET 
/ 22 
ASP.NET Export to Excel and Word using VB.NET and C#
