Controls in UpdatePanels may not cause a postback
An interesting lesson learned during my Atlas presentation at the Calgary Code Camp that had to do with postbacks within an UpdatePanel. My application contains, at startup, a textbox, three buttons and two empty GridViews. As you search for music, both GridViews get populated. Click the image at the right for a sample.
The bottom GridView contains a LinkButton column in the far left that allows you to remove that row from the GridView. Since it's a LinkButton, this causes a postback. To be more specific, this causes the javascript function __doPostBack to be called. The __doPostBack function is output into the page at runtime by .NET although what actually performs this function is something I've never looked into. As far as I know, its job is to submit the form to itself so that the code-behind can be called. It is called by any control that causes a postback.
What I discovered is that if there are no controls that cause a postback, the __doPostBack function is not generated. So in the normal ASP.NET version of my application, the function is not generated at startup because the only controls are a textbox and three buttons. (The buttons are rendered as Submit buttons so do not need a mechanism to cause a postback.) But when the user adds a song to the selected music list, this causes a LinkButton to be generated in the second GridView and .NET will then generate the __doPostBack function. So far, so good. No problem in the normal ASP.NET world.
Switching to Atlas: We wrap the GridViews in UpdatePanel controls so that when the user clicks Search or Add to Selected, we don't actually refresh the entire page, just the GridViews. Herein lies the problem. When the page first loads, there are no controls that require the __doPostBack function so it isn't generated. When the user clicks Add to Selected, Atlas takes over and retrieves the HTML required for the UpdatePanel but nothing else. Well, that's not entirely true. It does retrieve a little more info but the important part is that it retrieves the HTML for the second GridView which now includes LinkButtons. These LinkButtons have references to a __doPostBack function that hasn't been generated because (I guess) that only happens when the entire page is reloaded. Essentially, Atlas is assuming that the __doPostBack function has been generated already at the page level.
The workaround I used is to include the following code in the Page_Load event:
Page.ClientScript.GetPostBackEventReference( new System.Web.UI.PostBackOptions( this.ButtonPlay ) );
This generates a PostBack reference for the play button. The button doesn't technically need one but I had to pick some control to pass in. The side effect I was looking for is that the __doPostBack javascript function is going to be generated every time the page loads now, including the first time. And in the Atlas version, that's the only time the page is loaded.
So if you are clicking on controls and getting an “object not set to a value” javascript error in UpdatePanel controls, see if the __doPostBack function actually exists in your page source. If not, you'll need to add it.