I ran into a situation recently where I needed to select a set of data, present it to the user, and then give them the option to process each item individually or all items automatically. Problem was, the item processing task was long running, which complicated the “process all items” scenario. Looping through each item and processing it all on the server side would’ve been easy enough to accomplish, but the chances of the user sitting through the 7 minute postback for 20 items was next to nil.

What I really needed was incremental progress feedback, so the user could see an update as each item was processed. Luckily, I did have control over my user’s browser version and settings, so client scripting was available. With that in mind, this is the solution I came up with:

Display the Items and Interface

This sets up some test data, a repeater to display it, and the button controls to initiate processing. Note the runat and ID attributes of the body tag. This is important later.

Event Handler and Item Processing Code

This code sets up the event handler for the buttons in the repeater and a fake item processing function to simulate a delay and give visual feedback.

Multiple Postback Magic

This returns a JavaScript postback function call reference for the Button control in the repeater item[index] and places it in body.OnLoad. For example, when called on index 0, it will return __doPostBack(‘Repeater1$ct100$Button’, ‘Multi’). Calling this JavaScript code is identical to manually clicking the button, additionally including the ‘Multi’ event argument.

Since the document’s body tag has a runat=”server” and ID attribute, we can easily add this postback call to the OnLoad event of the body. It’s important to add the script this way instead of using RegisterClientScriptBlock or RegisterStartupScript, because they will insert the client script before any controls are rendered and most browsers will continue with the next postback before waiting for the rest of the page to render. Using body.OnLoad gives the full page time to load and render, then immediately proceeds to the next postback.

Adding the ‘Multi’ event argument is necessary so that we can distinguish between a user clicking the button and the automatic chain submission events. The argument will be available via Request.Form[“__EventArgument”]. With that in mind, it’s time to modify Repeater1_OnCommand to play its part in the sequence:

What this does is check __EventArgument for the ‘Multi’ parameter. If it’s there, then this is part of a multiple submission and we need to check which index we’re on. If it’s not the last one, call EnableSubmitScript on the next index to continue the multiple submission cycle.

Finally, we need an event handler for the All button, to kick things off:

I chose to go ahead and process item 0 there, and then start the multiple submit cycle with 1 if there is more than one repeater item. This could be cleaner by simply replacing the whole thing with EnableSubmitScript(0), but it adds an extra postback to the beginning that I didn’t care for.

That’s it! Now, when the user clicks “All” it loops through each repeater item and automatically submits each one in sequence. Being able to see the process step affecting each item in real time is invaluable feedback for the user. Of course, the obvious next step is to convert the repeater items to AJAX UpdatePanels and use a ScriptManager to control the processing instead.

Code for this example: SequentialUpdates.zip