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.
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 ) );