FileUpload control does not work in Update Panel and workaround

All file upload controls (includes asp, telerik, componentart, component factory and others) does not working in any AJAX update panels. This means if your upload control located in an update panel, control does not post the file. If you look to the posted file property of the control, you will see it null.

This is a limitation comes from the XmlHttpRequest component, used in all AJAX frameworks for asynchronous calls to the application. In order to upload a file you should perform a full page postback.

<asp:updatepanel id=”UpdatePanel1″ runat=”server” updatemode=”conditional”><br /><triggers><br />  <asp:postbacktrigger controlid=”Button1″><br /></triggers><br /><contenttemplate><br /><ews:datepicker id=”DatePicker1″ runat=”server” usingupdatepanel=”True” onselectionchanged=”DatePicker1_SelectionChanged”><br /> <asp:label id=”Label1″ runat=”server”></asp:Label><br /> <asp:fileupload id=”FileUpload1″ runat=”server”><br /> <asp:button id=”Button1″ runat=”server” text=”Upload” onclick=”Button1_Click”></contenttemplate><br /></asp:UpdatePanel>

The key is at the Triggers. Please note this will post a full postback even it’s inside a Update Panel.

Solutions are actually available for gmail like async file upload using iframe:

http://vinayakshrestha.wordpress.com/2007/03/13/uploading-files-using-aspnet-ajax-extensions/

http://msmvps.com/blogs/luisabreu/archive/2006/12/14/uploading-files-without-a-full-postback.aspx

Webpart and AJAX – do not forget the web.config

To enabled Ajax on your SharePoint site, you have to modify the web.config file as instructed here http://asp.net/AJAX/Documentation/Live/ConfiguringASPNETAJAX.aspx.

The last 2 parts can be skipped if that doesn’t apply to your case.

The good news is that this web.config file can be safely copied over in deployment. Actually it can be used in other sites as a starting point as well. So far the only thing we modified our web.config is to add some SafeControls. So the web.config files aren’t much different from each other anyway. (Update on 12/18: This is not always true. Make sure you don’t have extra entries in the SafeControl list that you haven’t installed on the target server. Otherwise you will see error when you add new webpart)

Webpart and AJAX – second postback not working in UpdatePanel?

I successfully add a webpart with UpdatePanel. However the second post back doesn’t seem to trigger? Why?

Excerpt from Mike Ammerlaan’s Blog

Windows SharePoint Services JavaScript has a “form onSubmit wrapper” which is used to override the default form action. This work is put in place to ensure that certain types of URLs, which may contain double byte characters, will fully work across most postback and asynchronous callback scenarios. However, if your scenarios do not involve double byte character URLs, you may successful disable this workaround and gain the ability to use ASP.NET AJAX UpdatePanels.

To do this, you may need to register a client startup script which disables this workaround, in addition to resetting the default form action:

<script type=’text/javascript’>_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;</script>

This script may be directly embedded in the page. Or write a function like this:

private void EnsureUpdatePanelFixups()
{
if (this.Page.Form != null)
{
string formOnSubmitAtt = this.Page.Form.Attributes["onsubmit"];
if (formOnSubmitAtt == “return _spFormOnSubmitWrapper();”)
{
this.Page.Form.Attributes["onsubmit"] = “_spFormOnSubmitWrapper();”;
}
}
ScriptManager.RegisterStartupScript(this, typeof(UpdatePanel), “UpdatePanelFixup”, “_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;”, true);
}

This solves the second post back problem.

Webpart and AJAX – tricks on creating ScriptManager

ScriptManager object is required if you want to use AJAX (Microsoft Atlas) in your webpart. In a ASPX page, there should only be one instance of ScriptManager object. However as just a component of a frame work/page, your webpart has no knowledge if the main page (or other web parts) has created the ScriptManager or not. There are 2 options.

One options is to modify the master page to create the ScriptManager object declaratively. Open \12\TEMPLATE\GLOBAL\default.master (or locate it by <site url>/_catalogs/masterpage). Add the following into the markup of your page. A recommended location is right beneath the WebPartManager registration (<WebPartPages:SPWebPartManager id=”m” runat=”Server” />, line 25 in above file):

<asp:ScriptManager runat=”server” ID=”ScriptManager1″ EnablePartialRendering=”True”></asp:ScriptManager>

However, replying on master page to create the object is not very convinient considering deployment and future maintenance. You have to deploy the master page together with your web part, and if there is any design change and new master page is used, you code will break if above script is forgot in the new master page.

So I recommend dynamically create the ScriptManager in your own web part. Then you face 2 issues:

1. What if the page already has, or another web part already created one?
2. For Get and Post request, the event sequence is different. How to make sure the ScriptManager is created in the right order?

The first issue can be addressed by putting your creation part in a try catch blog – of course you are running risk of ignoring legitimate exceptions. To address the second problem, you can check if there is already such object in the Controls collection. I have a AddScriptManager():

protected void AddScriptManager()
{
try
{
if (Controls.IndexOf(scriptManager) < 0)
{
scriptManager.EnablePartialRendering = true;
Controls.Add(scriptManager);
}
}
catch { }
}

(The scriptManager object is created beforehand.)