Ask Microsoft
Detecting a Post-pack
And Persisting Design-time Properties for User Controls
By Rob Howard
We ve had some great questions. I ll start this column with a question about controlling page refresh when using the automatic post-back feature, a feature available on several of the ASP.NET server controls.
Is there any way to stop page refresh when your auto post-back is set? Anonymous
Automatic post-back is a feature several ASP.NET server controls support. The feature allows for a form element, such as a drop-down list, to perform a post to the server automatically whenever a value changes. The following code enables this feature:
<asp:DropDownList
id=DropDownList1
runat="server"
AutoPostBack="True">
...
</asp:DropDownList>
By default, this is not enabled. When enabled, however, a small amount of JScript is embedded in the document returned to the calling browser. This client-side JScript code is what enables the automatic post-back functionality.
All ASP.NET pages completely re-execute on each request. That behavior is inherent unless, of course, you add code to change this behavior.
To prevent the page from executing in its entirety during post-backs, you need to modify code paths that execute on each request, so that they check for the IsPostBack property.
The IsPostBack property, which is a property of the base Page class, is set to True when an HTTP post to the page is performed from it. The default value is False. A great example of this is a situation in which a drop-down list box has its AutoPostBack property set to True, and the user changes the selection. When the change occurs, the client-side JScript executes to post the change back to the server. When ASP.NET receives the request, it is able to determine whether the request is a post-back. If it is, the value of IsPostBack is set to True.
Then, user code can be written to allow the developer to control the execution based on the current state of the page. For example, whenever a page is executed, the Page_Load event is raised. Code within the Page_Load event may look like this:
Sub Page_Load(sender as Object, e as EventArgs)
' Populate drop down list
PopulateProductCategoryDropDown()
End Sub
In the previous code, you have a scenario that works as follows:
1) When the page first loads, you need to execute PopulateProductCategoryDropDown to fill the initial drop-down list so your user has something to select.
2) When a selection is made in the ProductCategoryDropDown, an event (not shown) is wired up to handle the SelectedIndexChanged event to call additional code (e.g., populate a DataGrid of available inventory).
In the above design, when an automatic post-back occurs or any post-back occurs, for that matter the Page_Load code is re-executed. In other words, ProductCategoryDropDown is refreshed, and the selected item is not displayed. You could easily fix this by using the IsPostBack property:
Sub Page_Load(sender as Object, e as EventArgs)
' Populate drop down list on the first request
If (Not Page.IsPostBack) Then
PopulateProductCategoryDropDown()
End If
End Sub
The answer to the question is that you can prevent the auto-refresh of the page by using the IsPostBack property to determine the current state of the request. Then, based on the value, execute the appropriate code paths.
I have a user control. One of the properties is a collection named cValueItems. This collection consists of a ValueItem with the properties Name and Value. When I use this control on a form in Visual Studio .NET, I see the Collection Editor button and can click it and add values. However, after hitting [F5] to run the application, the collection items are not displayed in the user control. Michael Hensen
Believe it or not, this is the expected and correct behavior. For those who don t know, a user control is an ASP.NET page that can be reused (as a control) within other pages. The main difference is that rather than using the extension aspx, user controls use the extension ascx. These are fully functional controls like the ASP.NET server controls that ship with the product, such as DataList. The difference is that they are not compiled assemblies, but rather text files that are compiled on first use. For the remainder of the discussion I ll use server controls to refer interchangeably to both user controls and compiled server controls. The principles I m covering apply to both.
When working with server controls, there are two different modes you need to think about:
- The design-time mode When a server control is used in the Visual Studio .NET design-time environment, it is possible to set properties on the control and get a design time experience. This allows the developer building the application to receive immediate feedback on what the run-time experience or layout should look like. A great example of this is the DataGrid control that allows the developer to apply auto-formatting templates to the control at design time, which are rendered correctly at run time.
- The run-time mode When a server control is used within an ASP.NET application that is executing on the server and responding to user requests, the control is said to be in run-time mode.
The scenario Michael is seeing is due to the innate support of design-time property editing within Visual Studio .NET. To take it to the next level and allow the properties set at design time to be available at run time also, an additional step needs to be taken.
Take for example, the Performance Counters control (accessible with full source in the http://www.asp.net server control gallery). The PerformanceCounter class exposes a Counter property of type PerformanceCounterItemCollection. This allows the developer to select multiple performance counters for which the control will then render values. The key to enabling the selecting of performance counters at design time and then displaying of the selected counters at run time is the use of this attribute:
[PersistenceMode(PersistenceMode.InnerProperty)]
The above attribute instructs the Visual Studio .NET designer to persist any values set at design time as properties of the control. At run time, these properties are applied, and the control renders as expected.
By adding this attribute to the cValueItems property, you should be able to support design-time to run-time property persistence for your controls.
That s it for this installment. To submit questions for the Ask Microsoft column, send e-mail to [email protected]; we ll send an ASP.NET T-shirt to the person who submits the best question.
Rob Howard is a program manager on the ASP.NET team. He also writes the Microsoft Developer Network s Nothing but ASP.NET column and is a co-author of Professional ASP.NET, from Wrox.
Tell us what you think! Please send any comments about this article to [email protected]. Please include the article title and author.
