So, you are writing a custom control. And this custom control a two-way street -- meaning, you will be presenting something to the user and the user will be doing something with it or adding something to it that you need to capture.
The IPostBackDataHandler Interface
To handle the data that the user posted back, you would need to implement IPostBackDataHandler methods in your custom control. Your custom control class will have a signature like this:
public class MyCustControl : WebControl, IPostBackDataHandler
In your code, you need to implement two methods that belong to IPostBackDataHandler:
public bool LoadPostData(string postDataKey, NameValueCollection postCollection)
public void RaisePostDataChangedEvent()
In addition, you might also implement a TextChanged event handler. Let’s see the order in which this post back handling mechanism executes.
Order of Method Execution
Following figure shows the order in which various post back handling methods execute.
Figure 1. Control PostBack Sequence
Let’s look at various pieces of the above diagram:
Control Posted Back
The user has, for example, clicked some button on the page or on the control that makes the page to be posted back to the server. The server infrastructure recognizes that this particular control wants to handle its data that has been posted back.
LoadPostData
This is the first method that gets called. This method is discussed in further detail in this article: http://www.infinitezest.com/articles/loading-the-posted-data-on-the-post-back.aspx
The LoadPostData method has a bool return type. You want this method to return false, if your control state has not been changed. For example, if your custom control lets the user edit some text and no text has been changed between this and the previous postback, you would want to return false.
If your control state has been changed (for example, the user has changed the text), then you want to return true.
If this method returns false, then there is nothing else to do. The execution will go back to the page containing this control. However, if the return value is true (i.e. the control state has been changed), then the RaisePostDataChangedEvent() method will get called. From here, you can execute the OnTextChanged method.
public void RaisePostDataChangedEvent()
{
OnTextChanged(EventArgs.Empty);
}
public event EventHandler TextChanged;
protected virtual void OnTextChanged(EventArgs e)
{
if (TextChanged != null)
TextChanged(this, e);
}
Event Handling From a Custom Control
The above three methods form the crux of raising an event inside a custom control that can be handled on the page where it resides. In the above TextChanged is a delegate that holds the pointer to the method that will actually get executed at runtime. You can setup the name of that delegate method declaratively, as shown below (the local method awTest_TextChanged gets called from the OnTextChanged method above):
<ajw:AJAXWrite ID="awTest" runat="server" Height="500px" Width="750px" OnTextChanged="awTest_TextChanged" />
In that local delegate method, you can do whatever you want (with the information that the text in the custom control has changed). For example, here, we might want to save that changed text to the database.
/// <summary>
/// The text has changed.
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
protected void awTest_TextChanged(object sender, EventArgs e)
{
// Save the text to the database.
}
