|
Design Custom Editor for a Property |
|
In the previous article we discussed type converters. Type converters come handy when you want to accept property values in plain text form. However, at times you may not want to allow the user to enter text values directly. You may want to present a custom value picker in the form of a dropdown control or a dialog box. This is possible with the help of Type Editors and this article examines them with an example.
|
|
Posted On : 30 Mar 2008 |
|
|
Supporting Complex Types in Property Window |
|
Whenever you set any property of a control in the property window, the property window needs to save this property value in the .aspx file. This process is known as code serialization. For properties that are of simple types (such as integer and string) this code serialization happens automatically. However, when property data types are user defined complex types then you need to do that work yourself. This is done via what is called as Type Converters. This article is going to examine what type converters are and how to create one for your custom control.
|
|
Posted On : 23 Mar 2008 |
|
|
Using Design Time Attributes |
|
Developing a nice custom control is just one part of the story. As a control author you should also pay attention about the experience of other developers who will be using your control. In most of the real world cases developers use Visual Studio as the IDE for developing .NET applications. You can enhance the experience of other developers using your control by providing proper designer support. For example, you can control how your control properties and events are displayed in property window and toolbox. A set of attributes often called as Design Time Attributes allow you to accomplish this.
|
|
Posted On : 16 Mar 2008 |
|
|
Creating Data Bound Templated Control |
|
Data bound controls are most popular amongst developers because of their verticality. Controls such as GridView and DataList are popular not just because they provide rich features out of the box but because they allow great deal of customization. To that end templates go a long way in providing a customized look and feel. The concept of templates can be extended to custom controls also. With templates in place you can customize the way your data is presented to the user. This lesson is going to illustrate how this can be done. |
|
Posted On : 05 Mar 2008 |
|
|
Creating Derived Controls |
|
In the previous lesson you developed a composite control by assembling existing server controls. There is one more technique to add to the functionality of the existing controls. You can extend existing controls and add/customize functionality as per your requirement. This way you avail the core functionality of the base control to create a tailor-made control meeting your requirement. The designer features of Visual Studio such as smart tags and dialogs that are available for the base control continue to remain available for the derived control also. |
|
Posted On : 05 Feb 2008 |
|
|
Creating Composite Controls |
|
So far in this series you developed controls by emitting raw HTML markup. As you will agree with me this can be tedious at times. Won't it be nice if you can assemble existing controls of ASP.NET and render them as a part of your control? In fact this is a common requirement in many cases and ASP.NET provides an easy way out. In this part you will develop a custom control that assembles existing server controls such as Label and TextBox. |
|
Posted On : 14 Jan 2008 |
|
|
Handling Post Back Events |
|
Post back data is not the only thing that you may want to deal with in your custom controls. You may want your control to cause a post back and raise some server side event such as Click or SelectedIndexChanged. Handling a post back event requires that your control implements IPostBackEventHandler interface. In this article I explain how that can be done.
|
|
Posted On : 31 Dec 2007 |
|
|
Handling Data After Post Back |
|
In the last two lessons you were introduced with rendering of custom controls. Often your custom controls consist of input controls that allow users to edit data. The new data entered by the user must be persisted across post backs. In this lesson you will learn just that. |
|
Posted On : 17 Dec 2007 |
|
|
Persisting State Information |
|
In the previous lessons you developed HyperLinkGroup control. The control is working as expected but it has one limitation. It can't retain its state information across post backs. For example, if you set the SourceFile property programmatically to some other XML file then across post backs it won't remember the new file name. In this lesson you will learn two ways to overcome this limitation. |
|
Posted On : 02 Dec 2007 |
|
|
Adding support for styles |
|
In the previous lesson you learnt to develop a basic control. Your control inherited from the Control base class and emitted some HTML markup by overriding the Render() method of the base class. Though the control worked fine it lacked one important feature - support for formatting properties such as Font and ForeColor. Fortunately, the WebControl class from System.Web.UI.WebControls namespaces comes with inbuilt support for such properties. Instead of inheriting your control from the Control base class if you inherit from the WebControl control then your custom control can also avail these features. This lesson will teach you to do just that. |
|
Posted On : 11 Nov 2007 |
|