Using __doPostBack, The ProcessAjaxPostback Method

For those looking to get up and running with ASP.Net AJAX, using the following design patterns can do wonders for keeping your code clean and organized, while also helping keep your sanity when working with complex pages.

The first point to address is how we actually fire off partial page postbacks.  ASP.Net will do this automatically when using server controls within an updatepanel, or by using triggers, but these built-in features leave a lot to be desired.  For example, what if I want to fire off a postback from something other than an ASP.Net server control?

AJAX __doPostBack

In the example above, I’d like to do a postback when clicking on either of the divs within my update panel.  By calling the __doPostBack function directly, I’m able to fire off a postback as well as specify both the EventTarget and EventArgument variables.  This offers a HUGE amount of flexiblilty as we’ll see later.   Also Notice the hidden input fields, and how they have the same name as parameter 1 of the __doPostBack command.  This has the same effect as adding an UpdatePanel Trigger, and tells ASP.Net that when cmdSaveRecord is fired, the UpdatePanel upDemo should be reloaded.  If you leave this out, the entire page will be reloaded.  Note that you can place the hidden field in any UpdatePanel that you like, and only that updatepanel will be refreshed, regardless of where you execute __doPostBack from.

Now let’s look at the server side where we’ll be processing these Ajax Postbacks.

AJAX ProcessAjaxPostback

I use the code structure above for every page that does any type of postback, whether it’s Ajax enabled from an UpdatePanel or a full page postback.  This allows all postback handling code to be centralized in the ProcessAjaxPostBack method.  Notice that the first task of this method is to grab the EventTarget and EventArgument parameters.  These are the two parameters I passed in to the __doPostBack method from the client side.  Following this is an if/elseif loop which examines the first parameter and executes the appropriate code.  On complex pages, this function will get rather large, so It’s a good idea to build individual functions to do the work for each postback.  See the calls to SaveRecord and DeleteRecord above.

I use the code above in all of my web applications and have not run into any roadblocks or limitations.  I find it keeps my source code clean and understandable, on simple and complex pages.  I hope you enjoyed this article and I look forward to hearing your feedback!

IOS5 Multi-Threaded App Updates

After installing IOS5, I noticed I had 15 app updates waiting.  So, I hop over to the app store, click the “Update All” button, and set my phone down fully expecting a 15 minute update, one app after the next.  Then, to my pleasureful surprise, I see blue on 6 progress bars on my home screen.  I then slide to the right one screen and see 4 more blue bars.  That’s right, 10 apps are downloading and updating simultaneously.  This is a great improvement over the former single threaded update pattern.  Thanks for the nice new feature Apple!  Now if you’ll just unblock Siri for iPhone 4 users, we’ll really love you.

How to Manipulate the DOM before postback

Much frustration has arisen from the fact that changes made to the DOM in the initializeRequest method are not reflected on the server side. The problem is, the ViewState has already been wrapped up at this stage, and there is no other upstream method from initializeRequest.

There is a way around this problem, however. The answer is to simply cancel the postback, make your changes, and relaunch the postback. This causes the ViewState to be wrapped up after your new postback is initiated.  Here’s the code:


var bSecondPass = false;

function initializeRequest(sender, args){
//make your changes to the DOM here
var prm = Sys.WebForms.PageRequestManager.getInstance();
bSecondPass = true;
__doPostBack(args.get_postBackElement().id, document.getElementById(“__EVENTARGUMENT”).value);
bSecondPass = false;

I’ll soon be writing an article on how this can be used to make the TinyMCE rich text editor play nice with ASP.Net Ajax UpdatePanels.  I’ve written a nice little TinyMCE Asp.Net Plugin that I’m going to package up and share with you guys.  Stay tuned!

Databind a Strongly Typed List to a ListView

I tirelessly searched Google for a way to databind a strongly typed list to an Asp.Net ListView control without any good results, so now that I’ve figured this out, I thought I’d post it for the sake of others in the same boat.  This is really very simple.

From what I can tell there is no Design View support for DataBinding to a ListView.

You can, however, bind the ListView from the code behind, which I believe is a lot cleaner anyway.

List<string> lSampleList = new List<string>();
lvMyListView.DataSource = lSampleList;

<asp:ListView ID=”lvMyListView” runat=”server”>
<%# Container.DataItem %>

Notice that there’s no need to use the Eval() method, because there’s only one value we can get at.  Therefore You must use the Container.DataItem property instead.  Hope this helps!

Visual Studio Build Time Cut By 85%

If you’re an ASP.Net Developer reading this post, you’re probably frustrated with the amount of time it takes to build and launch an ASP.Net web page, especially when working with complex multi-project solutions.  The interesting thing is the majority of the wait time is post-build, while the web server (either .Net Dev Server or IIS) recompiles the code for every page on your site.  In order to pinpoint the hardware bottleneck, I opened an instance of Resource Monitor while compiling and running one of my larger web solutions.  Interestingly, the major bottleneck appeared to be the Disk I/O.  Note that your CPU can also bottleneck the process, but the Hard Disk is the number 1 culprit causing the slow compilation.

Using the solutions below, I was able to cut the build time on my current project down from over 1 minute to about 7 seconds.  Here are the two solutions I’ve found to the problem.

Solution #1
The first successful solution was to install a Solid State Hard Drive.   Solid state drives use flash memory to store data, which provides sub-millisecond access times when locating files.  ASP.Net compilation involves intense I/O of small files, which is the #1 strength of solid state drives.  After much research, I’ve found the Intel X25-M to currently be the clear winner in terms of price/performance for solid state hard drives.   I bought mine at $500, but you can now get one for less than $250.  Newegg usually has the best price on these:

Intel X25-M Mainstream SSDSA2M080G2XXX 2.5″ MLC Internal Solid State Drive (SSD)

This not only greatly improved build times, but also made all of my apps snappy. Photoshop loads up instantly now, instead of the annoying 10 second delay.   Note the 80Gb storage capacity is a limitation, so you’d probably need a secondary storage drive. Also, solid state drives are great for laptops, b/c they aren’t sensitive to shock like traditional hard drives.

Solution #2 (The Even Faster and Free Solution)
If you’ve got a lot of RAM, create a 500Mb NTFS RAM Drive, and direct Visual Studio to use it as the temp directory.  99% of that file I/O is in the temp directory, so this is a free way to instantly speed up your builds.

If you created your RamDrive as R:\, just adjust the web.config as follows:
<compilation tempDirectory=”R:\” debug=”false” />

Here’s the free RamDrive software I use.   It’s shareware, so it has an annoying popup in the taskbar unless you register it (There is no popup in Windows 7 however).   There are 2 downloads you need.

I’m currently the only developer in our company.   There’s no way I would’ve been able to keep up with the workload if I was still dealing with that +1 minute build time.  I Hope you can use these tips to save yourself and your organization a boatload of time.

Please leave any other tips for improving build times in the comments section below.  Thanks!

.Net Framework 4.0 Update Panel Problems

For those of us who use the __doPostBack method in combination with hidden fields to control updatepanel post backs, the latest .Net 4.0 release presents a small problem.   __doPostBack calls without an associated control id no longer cause a full postback when executed from an updatepanel.  Somehow, .Net knows which update panel you execute the __doPostBack call from and in response only updates the associated panel.   Click here for more information on launching post backs directly using JavaScript.

This poses a problem if you have written code that actually needs to launch a full page postback from within an updatepanel.   The work around is pretty simple, though it’s quite annoying to browse through a multi-project solution and find every instance of this issue.


Whenever you want to launch a full page postback using the __dopostback command, you’ll need to include a matching hidden field outside of all update panels.  Here’s a sample:

<asp:UpdatePanel ID=”up1″ runat=”server”>
<input type=”button” onclick=”__doPostBack(‘cmdDoSomething’, ”);”>

<!– Force Full Page Postback Here –>
<input type=”hidden” id=”cmdDoSomething” >

I’m very thankful for FireBug, as I spent about 5 hours using it to track down and resolve this issue.  I’d love to hear from anyone who may know more about underlying changes to AJAX functionality in the new 4.0 Framework.  I’m concerned that there may be other hidden problems arising as I convert more sites over to 4.0.

Return top

__doPostBack Site Info

A discussion of ASP.Net Ajax design patterns and best practices.