Eilon Lipton's Blog

In ASP.NET AJAX's ScriptManager control there are two properties that seem quite similar, but are in fact very different:

A recent question on one of our internal mailing lists asked where the definition for the Bind() method is located in ASP.NET. The asker had located the definition of the Eval() method on the TemplateControl class, but the Bind() method was nowhere to be found, even using Reflector.

If you're familiar with databinding in ASP.NET 2.0, you probably know that for read-only values such as Labels you can use the Eval() statement, and for read-write values such as TextBoxes (also known as "two-way databinding") you can use the Bind() statement. Where does that Bind() statement come from?

To the surprise of many readers, there isn’t a bind method in ASP.NET! When ASP.NET parses your file and sees you're using a databinding expression (in the angle-bracket-percent-pound format, "<%# %>") it has special-case code to parse for the Bind syntax and generates some special code for it. When you use <%# Bind("Name") %> it's not a real function call. If ASP.NET parses the code and detects a Bind() statement, it splits the statement into two parts. The first part is the one-way databinding portion, which ends up being just a regular Eval() call. The second part is the reverse portion, which is typically some code along the lines of "string name = TextBox1.Text" that grabs the value back out from where it was bound.

In ASP.NET 2.0 we added several new features to make globalizing and localizing an application easier than ever before. One of the coolest features is the ability to declaratively localize entire controls as well as individual properties of controls. However, localization would be useless without the ability to choose which language and culture you want to display to the user. In many sites the user gets to choose their own language through some customization interface. So how does an ASP.NET developer set the culture?

There are three ways that I can think of that you can use to set the culture of a page:

1. Set it in the web.config's <globalization> section. This is a great option if you want to force an entire site to have the exact same behavior when it comes to selecting a culture. Set the values of Culture and UICulture to "auto" to have ASP.NET auto-detect the browser's culture through the Accept-Language request header.
2. Set it in the <%@Page %> directive. This works in the same way as the <globalization> section but is per page, including the auto-detect logic.
3. For the most advanced customization of the selected culture you can override the page's InitializeCulture method and set the page's Culture and UICulture properties through code. The InitializeCulture method was added in ASP.NET 2.0 specifically for this scenario. We had to introduce a method that executes before the control tree is built such that when controls have their properties set they will use the appropriate resource set. You can place all this code in a single page base class and use the pageBaseType attribute of the <pages> section in web.config to have it be the base class for all pages in the application.

But how about setting the culture in the page's Init or Load phases? As it turns out, there are no phases of the page and control lifecycle that execute early enough so that every component on the page will realize the new culture settings. By the time Init happens, all the top-level controls on the page already have their properties set. Only dynamic controls, such as those inside templates, will realize the new culture settings since they typically get added as late as the Load or PreRender phases. InitializeCulture executes before the page and control lifecycle so that everyone can see its effects.

A typical ASP.NET server control will store at least some of its properties in ViewState. For example, the Label control saves the value of its Text property in ViewState so that on following postbacks the value does not need to be explicitly set again. In the first part of this series (which I hope will be extensive) we'll see how to write general unit tests for a control, and then write a unit test that ensures a property is being saved in ViewState.

Since ASP.NET 2.0 was released in 2005 many of you have taken advantage of the new data source control controls. Drop a GridView on the page. Bind it to a data source. Check a few checkboxes. Run the page. Go home early!

Let's start out with an innocent control that registers a simple script file include:

As many people have noticed in their AJAX-enabled pages, file uploads do not work when doing an async postback. To my knowledge there's no way to support this scenario due to the browser's security restrictions. To understand why the upload doesn't work it's important to understand how async postbacks are performed and how that's different from how the browser performs a regular postback.

If you've used the Microsoft ASP.NET AJAX UpdatePanel control, there's a good chance you've hit the "Sys.WebForms.PageRequestManagerParserErrorException" error.