Siderite's Blog

and has 0 comments
Yay! My first real SilverLight post :)

Anyway, the problem is with controls in SilverLight that expect an URI as a parameter. It doesn't work. After trying all kind of stuff and googling a litle I found out that
  1. the path is relative to the web application ClientBin directory
  2. the path cannot contain .. or other directory/URI navigation markers like ~
  3. the SilverLight control does not have access to a Request object like a web page does


This link already discusses it: Silverlight 2.0 Beta 1 Uri inconsistency, but I also have an additional solution to the ones listed there.

Here are the solutions for this:
  • Provide an absolute Uri either statically or by generating it with this piece of code: 
    New Uri(Application.Current.Host.Source.AbsolutePath + "../../../video.wmv", UriKind.Absolute)
  • Copy the images, videos, files into the ClientBin directory then only provide their name
  • Create virtual directories inside ClientBin that point to your resource directories. For example create a virtual directory Videos that points to the ~/Resources/Videos folder in the site, then simply use Videos/video.wmv as the URI


Of these three, the last I find the most elegant, even if the setup of the website itself might be rendered a lot more difficult by this.

and has 3 comments
ASP.Net 2.0 added a very useful thing, the '~' sign, which indicates that a path is relative to the application directory. Since the application itself should be indifferent to its name, this little thing comes in useful when trying to set the location of user controls, style sheets and so on. The problem is that this feature only applies to user controls. That is not a problem for most tags, since even a link tag can be set as a user control with a runat=server attribute.

The problem comes when trying to set the location of javascript script blocks. A script block with runat=server must be a server code block by definition, i.e. C# or VB, whatever the site language is set to. One of the solutions often used to solve this is to use a code block inside the src attribute of the javascript block like this:
<script language="Javascript" type="text/javascript" 
   src='<% =ResolveUrl("~/scripts/myScript.js")%>'></script>
.

But this is still a nasty issue, because of the dreaded The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>). error. As in the post I linked to, the solution for this is to place all external script blocks within a server control like a PlaceHolder or a even a div with the runat=server attribute set. The drawback to this solution is that you can't do that in the <head> section of the HTML output.

The other solution is to use from within the server code the ScriptManager.RegisterClientScriptInclude method to add the script programatically to the page. While this is elegant, it also defeats the purpose of the aspx page, that is to separate content from code.

and has 1 comment
Somebody asked me how to add things at the end of an AutoCompleteExtender div, something like a link. I thought it would be pretty easy, all I would have to do is catch the display function and add a little thing in the container. Well, it was that simple, but also complicated, because the onmousedown handler for the dropdown is on the entire div, not on the specific items. The link was easy to add, but there was no way to actually click on it!

Here is my solution:

function addLink(sender,args) {
    var div=sender.get_completionList();
    if (div) {
        var newDiv=document.createElement('div');
        newDiv.appendChild(getLink());
        div.appendChild(newDiv);
    }
}

function getLink() {
    var link=document.createElement('a');
    link.href='#';
    link.innerHTML='Click me for popup!'
    link.commandName='AutoCompleteLinkClick';
    return link;
}

function linkClicked() {
    alert('Popsicle!');
}

function ACitemSelected(sender,args) {
    var commandName=args.get_item().commandName;
    if (commandName=='AutoCompleteLinkClick') linkClicked();
}


The AutoCompleteExtender must have the two main functions as handlers for the item selected and popup shown set like this:
<ajaxControlToolkit:AutoCompleteExtender OnClientItemSelected="ACitemSelected" OnClientShown="addLink" ...>


Now, the explaining.

First we hook on OnClientShown and add our link. The link is added inside a div, because else it would have been shown as a list item (with highlight on mouse over). I also added a custom attribute to the link: commandName.

Second we hook on OnClientItemSelected and check if the selected item has a commandName attribute, and then we execute stuff depending on it.

That's it folks!

and has 4 comments
We have this web application that needs to call a third party site that then redirects back to us. The other app is using a configured URL to redirect back. In order to develop and debug the application, we used a router redirect with a different port like this: the external site calls http://myExternalIp:81 and it gets redirected to my own computer on port 80.

I was amazed to notice that when entering my local page, Request.Url would be in the format http://myExternalIp, without the 81 port. As the page was executed in order to debug it, I was baffled by this behaviour. I tried a few things, then I decided to replicate it on a simple empty site and there it was. The only thing I could find that had any information about the original port number was Request.Headers["Host"] which looked something like myExternalIp:81.

I guess this is a bug in the Request object, since it uses the port of the actual server instead of the one of the request, since my server was responding on port 80 on localhost and not 81.

Here is a small method that gets the real Request URL:


 public static Uri GetRealRequestUri()
 {
     if ((HttpContext.Current == null) || 
         (HttpContext.Current.Request == null))
         throw new ApplicationException("Cannot get current request.");
     return GetRealRequestUri(HttpContext.Current.Request);
 }

 public static Uri GetRealRequestUri(HttpRequest request)
 {
     if (String.IsNullOrEmpty(request.Headers["Host"]))
       return request.Url;
     UriBuilder ub = new UriBuilder(request.Url);
     string[] realHost = request.Headers["Host"].Split(':');
     string host = realHost[0];
     ub.Host = host;
     string portString = realHost.Length > 1 ? realHost[1] : "";
     int port;
     if (int.TryParse(portString, out port))
         ub.Port = port;
     return ub.Uri;
 }

and has 0 comments
Just a short infomercial. Response.Redirect(url) is the same with Response.Redirect(url,true), which means that after the redirect, Response.End will be executed. In case you get a weird 'Thread was being aborted' exception, you probably have the Redirect/End methods inside a try/catch block. Remove them from the block and it will work. Probably the ending of the Response session doesn't look good to the debugger and that particularily obtuse exception is thrown.

If you absolutely must put the thing in a try/catch block, just put everything EXCEPT the Redirect/End. Another option (only for Response.Redirect) is to add a false parameter so to not execute Response.End.

and has 0 comments
How can I get some content from javascript (like a string) and send it to the client as a file? I don't have access to the content I want to send from the server.

This was a question posed to me in a rather more complex way: how do I take some file content from a web service and send it to the client as as file without downloading the content to the web server first?

The simple answer right now: you cannot do it. If you guys know more about this, please let me know. I've exausted all avenues I could think of, but then again, I am no master of Javascript and html responses.

Here is what I have tried. Basically, I have a string like a html table and I want it sent to the client browser as an excel download. So I opened a new window with javascript and tried to write the content there:
var win2=window.open('');
win2.document.write(s);


It worked and it displayed a table. Now, all I wanted to do is add/change the html header content-type to application/vnd.ms-excel. Apparently, you can't do it from Javascript. Ok, how about getting the necessary headers from the ASP.Net server? (remember, the restriction was that only the file content should not come from the web server). So I created a new page that would render a completely empty page with the right headers:

protected void Page_Load(object sender, EventArgs e)
    {
        Response.Clear();
        Response.Buffer = true;
        Response.ContentType = "application/vnd.ms-excel";
        Response.AppendHeader("Content-Disposition", "attachment;filename=test.xls");
        Response.Charset = "";
        
        Response.Flush();
        Response.End();
    }


Then I just opened it in a new window (just ignore the browser pop-up filters for now) with 
var win2=window.open('PushFile.aspx');
win2.document.write(s);


What happened was that the page was just rendered like a normal page. How come? I change the code so that it would write the content after a few seconds. And I got this: first the browser asks me if I want to permit downloading the file, then, after a few seconds, the warning goes away and the string is displayed in the new window. I tried with document.createTextNode, it didn't work.

So far, none of my attempts to serve javascript content as a binary file worked. If you know of a way to achieve this, please let me know. Thanks!

Update:
Meaflux took a swipe at this request and came up with two delicious ideas that, unfortunately, don't really work. But I had no idea things like these existed, so it is very much worth mentioning.

First: the data URI. Unfortunately it is only supported by FireFox and such and has no way of setting a content-disposition header or some other way of telling the browser that I actually want it saved. It would work for an excel file, but an image, for example, would be opened in a browser window.

Second: the IE execCommand javascript function which has a little command called SaveAs. Unfortunately this would only work for actual HTML pages. Even if the browser would open a binary file, I doubt that a saveAs command would save it correctly.

Besides, both these options, as well as my own attempts above, have a major flaw: there is no way to send chunks of data as you are receiving them from the web service. What is needed it declaring some sort of data stream, then writing stuff in it and then declaring it programatically closed.

and has 0 comments

I've spent about half an hour trying to determine why the DataFormatString format would not be applied to cell values in a GridView. The short answer: set the HtmlEncode property of the BoundField to false!

Now for the long answer:

A while ago I wrote a small article about how to format the data in your autogenerated GridView columns. At the end of the post I added a small update that explained why I set the HtmlEncode to false. It was, in my opinion, a GridView bug.

However, I didn't realise at the time that the same thing applies to normal GridView BoundFields as well. The thing is, in order to display a value in a bound cell, it FIRST applies the HtmlEncoding to the value CAST TO STRING, THEN it applies the FORMATTING. Here is the reflected source:


/// <summary>Formats the specified field value for a cell in the <see cref="T:System.Web.UI.WebControls.BoundField"></see> object.</summary>
/// <returns>The field value converted to the format specified by <see cref="P:System.Web.UI.WebControls.BoundField.DataFormatString"></see>.</returns>
/// <param name="dataValue">The field value to format.</param>
/// <param name="encode">true to encode the value; otherwise, false.</param>
protected virtual string FormatDataValue(object dataValue, bool encode)
{
    string text1 = string.Empty;
    if (!DataBinder.IsNull(dataValue))
    {
        string text2 = dataValue.ToString();
        string text3 = this.DataFormatString;
        int num1 = text2.Length;
        if ((num1 > 0) && encode)
        {
            text2 = HttpUtility.HtmlEncode(text2);
        }
        if ((num1 == 0) && this.ConvertEmptyStringToNull)
        {
            return this.NullDisplayText;
        }
        if (text3.Length == 0)
        {
            return text2;
        }
        if (encode)
        {
            return string.Format(CultureInfo.CurrentCulture, text3,
         new object[] { text2 });
        }
        return string.Format(CultureInfo.CurrentCulture, text3, 
        new object[] { dataValue });
    }
    return this.NullDisplayText;
}



At least the method is virtual. As you can see, there is no way to format a DateTime, let's say, once it is in string format.

Therefore, if you ever want to format your data in a GridView by using DataFormatString, you should make sure HtmlEncode is set to false! Or at least create your own BoundField object that implements a better FormatDataValue method.

and has 2 comments
I wanted to write this great post about how to make Web User Controls that would have templates, just like Repeaters or GridViews or whatever, face any problems, then solve them. Unfortunately, MSDN already has a post like this: How to: Create Templated ASP.NET User Controls. So all I can do is tell you where to use this and what problems you might encounter.

I think the usage is pretty clear and useful: whenever you have as?x code that repeats itself, but has different content, you can use a templated Web User Control. The best example I can think of is a collapsable panel. You have a Panel, with some javascript attached to it, a hidden field to hold the collapse state, some buttons and images and texts to act as a header, but every time the content is different.

Now with the issues one might encounter. In Visual Studio 2005 you get an error, while in VS 2008 you get a warning telling you the inner template, whatever name you gave it, is not supported. This is addressed by the 
[ PersistenceMode(PersistenceMode.InnerProperty) ]
decoration of the ITemplate property of the control.
Then there is the issue of the design mode, where you get an ugly error in all Visual Studio versions: Type 'System.Web.UI.UserControl' does not have a public property called '[yourTemplatePropertyName]'. As far as I know there is no way of getting rid of this. It is an issue within Visual Studio. However, the thing compiles and the source as?x code is warning free. I think one could easily sacrifice some design time comfort to reusability.

and has 53 comments

Update: this fix is now on Github: Github. Get the latest version from there.

The scenario is pretty straightforward: a ListBox or DropDownList or any control that renders as a Select html element with a few thousand entries or more causes an asynchronous UpdatePanel update to become incredibly slow on Internet Explorer and reasonably slow on FireFox, keeping the CPU to 100% during this time. Why is that?

Delving into the UpdatePanel inner workings one can see that the actual update is done through an _updatePanel Javascript function. It contains three major parts: it runs all dispose scripts for the update panel, then it executes _destroyTree(element) and then sets element.innerHTML to whatever content it contains. Amazingly enough, the slow part comes from the _destroyTree function. It recursively takes all html elements in an UpdatePanel div and tries to dispose them, their associated controls and their associated behaviours. I don't know why it takes so long with select elements, all I can tell you is that childNodes contains all the options of a select and thus the script tries to dispose every one of them, but it is mostly an IE DOM issue.

What is the solution? Enter the ScriptManager.RegisterDispose method. It registers dispose Javascript scripts for any control during UpdatePanel refresh or delete. Remember the first part of _updatePanel? So if you add a script that clears all the useless options of the select on dispose, you get instantaneous update!

First attempt: I used select.options.length=0;. I realized that on Internet Explorer it took just as much to clear the options as it took to dispose them in the _destroyTree function. The only way I could make it work instantly is with select.parentNode.removeChild(select). Of course, that means that the actual selection would be lost, so something more complicated was needed if I wanted to preserve the selection in the ListBox.

Second attempt: I would dynamically create another select, with the same id and name as the target select element, but then I would populate it only with the selected options from the target, then use replaceChild to make the switch. This worked fine, but I wanted something a little better, because I would have the same issue trying to dynamically create a select with a few thousand items.

Third attempt: I would dynamically create a hidden input with the same id and name as the target select, then I would set its value to the comma separated list of the values of the selected options in the target select element. That should have solved all problems, but somehow it didn't. When selecting 10000 items and updating the UpdatePanel, it took about 5 seconds to replace the select with the hidden field, but then it took minutes again to recreate the updatePanel!

Here is the piece of code that fixes most of the issues so far:

/// <summary>
/// Use it in Page_Load.
/// lbTest is a ListBox with 10000 items
/// updMain is the UpdatePanel in which it resides
/// </summary>
private void RegisterScript()
{
string script =
string.Format(@"
var select=document.getElementById('{0}'); 
if (select) {{
// first attempt
//select.parentNode.removeChild(select);


// second attempt
//    var stub=document.createElement('select');
//    stub.id=select.id;
//    for (var i=0; i<select.options.length; i++)
//        if (select.options[i].selected) {{
//            var op=new Option(select.options[i].text,select.options[i].value);
//            op.selected=true;
//            stub.options[stub.options.length]=op;
//        }}
//    select.parentNode.replaceChild(stub,select);


// third attempt
var stub=document.createElement('input');
stub.type='hidden';
stub.id=select.id;
stub.name=select.name;
stub._behaviors=select._behaviors;
var val=new Array();
for (var i=0; i<select.options.length; i++)
if (select.options[i].selected) {{
val[val.length]=select.options[i].value;
}}
stub.value=val.join(',');
select.parentNode.replaceChild(stub,select);

}};",
lbTest.ClientID);
ScriptManager sm = ScriptManager.GetCurrent(this);
if (sm != null) sm.RegisterDispose(lbTest, script);
}



What made the whole thing be still slow was the initialization of the page after the UpdatePanel updated. It goes all the way to the WebForms.js file embedded in the System.Web.dll (NOT System.Web.Extensions.dll), so part of the .NET framework. What it does it take all the elements of the html form (for selects it takes all selected options) and adds them to the list of postbacked controls within the WebForm_InitCallback javascript function.

The code looks like this:

if (tagName == "select") {
var selectCount = element.options.length;
for (var j = 0; j < selectCount; j++) {
var selectChild = element.options[j];
if (selectChild.selected == true) {
WebForm_InitCallbackAddField(element.name, element.value);
}
}
}
function WebForm_InitCallbackAddField(name, value) {
var nameValue = new Object();
nameValue.name = name;
nameValue.value = value;
__theFormPostCollection[__theFormPostCollection.length] = nameValue;
__theFormPostData += name + "=" + WebForm_EncodeCallback(value) + "&";
}

That is funny enough, because __theFormPostCollection is only used to simulate a postback by adding a hidden input for each of the collection's items to a xmlRequestFrame (just like my code above) in the function WebForm_DoCallback which in turn is called only in the GetCallbackEventReference(string target, string argument, string clientCallback, string context, string clientErrorCallback, bool useAsync) method of the ClientScriptManager which in turn is only used in rarely used scenarios with the own mechanism of javascript callbacks of GridViews, DetailViews and TreeViews. And that is it!! The incredible delay in this javascript code comes from a useless piece of code! The whole WebForm_InitCallback function is useless most of the time! So I added this little bit of code to the RegisterScript method and it all went marvelously fast: 10 seconds for 10000 selected items.

string script = @"WebForm_InitCallback=function() {};";
ScriptManager.RegisterStartupScript(this, GetType(), "removeWebForm_InitCallback", script, true);



And that is it! Problem solved.

and has 0 comments
This is mostly a noob post, but I had to write it because I've had to work with a project written by a colleague of mine and her method of maintaining value across postbacks was to use HiddenFields. I will explore that option and the ViewState option.

First of all, what are the advantages of using a hidden field? I can see only two:
1. it would work even if ViewState is disabled
2. its value is accesible through javascript
The disadvantages are:
1. it creates additional HTML markup
2. it can only store stuff in string format
3. its value is accesible through javascript

I would not use the hidden field option mainly because it gives people the ability to see and change the value through simple javascript manipulation. It's a security risk, even if most of the times you don't really care about the security of some value maintained through postback. I would use it only when _I_ need to change that value through javascript.

For some code, I assume I want to store an integer value called MyValue. There will be a field called _myValue that will store the value during a cycle, but it is used mainly for caching (reading Request and ViewState is slow) and it is declared like this:

private int? _myValue;


Now, about the structure of such a code. The simplest method is to actually create a (or many) hidden field(s) in your page. You can then use the values directly. It is simple, but hardly maintainable:

Markup:

<asp:HiddenField id=hfMyValue runat=server>

C# code:

    public int MyValue
    {
        get
        {
            if (_myValue == null)
            {
                if (String.IsNullOrEmpty(hfMyValue.Value)) MyValue = 10;
                else _myValue = Int32.Parse(hfMyValue.Value);
            }
            return _myValue.Value;
        }
        set
        {
            hfMyValue.Value = value.ToString();
            _myValue = value;
        }
    }


I've wrapped the functionality of the hidden field in a property so I can easily use it through my code.

Another method of doing this is to use the RegisterHiddenField method of the ScriptManager like this:

C# code only:

    public int MyValue
    {
        get
        {
            if (_myValue==null)
            {
                if (Request["MyValue"] == null) MyValue = 10;
                else _myValue = Int32.Parse(Request["MyValue"]);
            }
            return _myValue.Value;
        }
        set
        {
            PreRender -= MyValue_Registration;
            PreRender += MyValue_Registration;
            _myValue = value;
        }
    }

    void MyValue_Registration(object sender, EventArgs e)
    {
        if (_myValue.HasValue)
            ScriptManager.RegisterHiddenField(this, "MyValue", _myValue.Value.ToString());
    }


As you can see, there is no need of my changing the markup. There is the ugly part of having to attach to the prerender event to register the hidden field because the ScriptManager doesn't have any way of accessing the registered hidden field after you did it or at least a way to un-register it. Registering it again doesn't change its value, either.

In both these cases the value is accessible through javascript:

<script>var myValue=parseInt(document.getElementById('<%=hfMyValue.ClientID%>').value);</script>
<script>var myValue=parseInt(document.getElementById('MyValue').value);</script>


But there is an easier way of storing the values through postback, and that is by using ViewState. In order to do that, your object needs only to be Serializable. It can be anything from a string to a complex DataSet. There is no way to access it through javascript, though. Here is the C# code for it:

    public int MyValue
    {
        get
        {
            if (_myValue == null)
            {
                if (ViewState["MyValue"] == null) MyValue = 10;
                else _myValue = (int)ViewState["MyValue"];
            }
            return _myValue.Value;
        }
        set
        {
            ViewState["MyValue"] = value;
            _myValue = value;
        }
    }


Doesn't that look a lot simpler? And the beauty of it is, the ViewState can be sent inside the markup, as in the default behaviour, but it can just as easily be stored on the server, either by using a SessionStatePersister or by other ways.

Update: Also, a more complicated, but a lot more flexibile way of doing things is described on the DimeBrain blog: Frictionless data persistence in ASP.NET WebForms.

and has 1 comment
This annoying error appeared out of nowhere in a project that used to work. I thought that the fault was of the new AjaxControlToolKit and the way it tries to register a CSS file. I was about to make really complex and , apparently, useless changes to my code until I've stumbled upon Rick Strahl's blog. It is not in the entry, but further down in the comments, but it's there.

Here is a distilled version: the error is not a page error, but a naming container control error. That means that if you do this in a PlaceHolder, let's say, it will only throw an error if the PlaceHolder has code blocks. The same applies to the header! The problem was not AjaxControlToolKit, but my own modifications to the MasterPage, where I had added script blocks with a dynamic URL.

So I added the script tags from the codebehind using this:

private void AddHeaderScript(string src)
{
HtmlGenericControl hgc=new HtmlGenericControl("script");
hgc.Attributes.Add("type", "text/javascript");
hgc.Attributes.Add("language", "JavaScript");
hgc.Attributes.Add("src", src);
Page.Header.Controls.Add(hgc);

}
. I don't know how this would work during an Ajax postback, but I wasn't interested in this, being a MasterPage thing. And it worked.

So, next time you get this error, be sure you know what control generated it. It can be solved by putting an extra PlaceHolder or, as is this case, replacing just some specific few code blocks.

and has 0 comments
Well, I don't know who still uses it, but I had this old application that we reused and it had a Login control in the login page (obviously!). And I got tired of always entering the name and password every time I tested the site, so I went to the username and password TextBoxes and added a Text="something" bit. And it didn't work.

Why? First of all the TextBox control with TextMode="Password" ignores the Text property completely. Then the Login control only acknowledges the values of the two TextBoxes on change.

The solution: add a value="something" instead of Text="something" and it will be added like an oldfashioned HTML attribute. And it will also fire Changed since the value the .Net control is string.Empty.

That's all, folks, remember to remove this in the production site :)

and has 8 comments
Well, someone asked me today about why his dynamically generated GridView throws a 'Object reference not set to an instance of an object.' exception at DataBind when he sets AllowPaging to true. I replicated the error and looked at the stack trace, it looked like this:
   at System.Web.UI.WebControls.GridView.BuildCallbackArgument(Int32 pageIndex)
   at System.Web.UI.WebControls.GridView.CreateNumericPager(TableRow row, PagedDataSource pagedDataSource, Boolean addFirstLastPageButtons)
   at System.Web.UI.WebControls.GridView.InitializePager(GridViewRow row, Int32 columnSpan, PagedDataSource pagedDataSource)
   at System.Web.UI.WebControls.GridView.CreateRow(Int32 rowIndex, Int32 dataSourceIndex, DataControlRowType rowType, DataControlRowState rowState, Boolean dataBind, Object dataItem, DataControlField[] fields, TableRowCollection rows, PagedDataSource pagedDataSource)
   at System.Web.UI.WebControls.GridView.CreateChildControls(IEnumerable dataSource, Boolean dataBinding)
   at System.Web.UI.WebControls.CompositeDataBoundControl.PerformDataBinding(IEnumerable data)
   at System.Web.UI.WebControls.GridView.PerformDataBinding(IEnumerable data)
   at System.Web.UI.WebControls.DataBoundControl.OnDataSourceViewSelectCallback(IEnumerable data)
   at System.Web.UI.DataSourceView.Select(DataSourceSelectArguments arguments, DataSourceViewSelectCallback callback)
   at System.Web.UI.WebControls.DataBoundControl.PerformSelect()
   at System.Web.UI.WebControls.BaseDataBoundControl.DataBind()
   at System.Web.UI.WebControls.GridView.DataBind()
   at Malaka.Page_Load(Object sender, EventArgs e) in c:\Inetpub\wwwroot\ScrollableFixedHeaderGrid\Malaka.aspx.cs:line 14
   at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
   at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
   at System.Web.UI.Control.OnLoad(EventArgs e)
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)


So, the error occurs at the BuildCallbackArgument method in the GridView object. I used Lutz Roeder's Reflector to see the source of the GridView object and I got to this piece of code:
        private string BuildCallbackArgument(int pageIndex)
        {
            if (string.IsNullOrEmpty(this._sortExpressionSerialized))
            {
                this._sortExpressionSerialized = this.StateFormatter.Serialize(this.SortExpression);
            }
            return string.Concat(new object[] { "\"", pageIndex, "|", (int) this.SortDirection, "|", this._sortExpressionSerialized, "|\"" });
        }


The error appears to be thrown by the StateFormatter property returning null. It's source is:
        private IStateFormatter StateFormatter
        {
            get
            {
                if (this._stateFormatter == null)
                {
                    this._stateFormatter = this.Page.CreateStateFormatter();
                }
                return this._stateFormatter;
            }
        }


Got it? It assumes you already added the GridView to a Page. Well, this is the usual issue with the GridView.

Solution: Add the GridView to your Page (or to a fictive Page) and then DataBind it.

and has 2 comments
Thanks for Raheel for presenting me this problem and the opportunity to fix it.

As you may know from a previous post of mine, Ajax requests differ from normal requests. At the Page level, the rendered content is changed to reflect only the things that changed in the UpdatePanels and the format is different from the usual HTML and it is also very strict. Any attempt to blindly add things to the string sent from the server will result in an ugly alert error. And who does indiscriminately add ugly content to your Ajax requests? "Free" servers that inject commercials in your pages!

So, what can you do? Patch the Ajax engine to remove the offending ads. Here is a simple example for a server that added crap at THE END of the content, crap that did not contain any '|' characters. This is important, as the patch looks for the last '|' character and removes all the things after it.

C# Code

private void LoadApplyPatch()
{
ScriptManager sm = ScriptManager.GetCurrent(Page);
if (sm == null) return;

string script =@"
if (window.Sys&&Sys.WebForms&&Sys.WebForms.PageRequestManager) {
Sys$Net$WebRequestExecutor$get_responseData=function() {
if (arguments.length !== 0) throw Error.parameterCount();
if (!this._responseAvailable) {
throw Error.invalidOperation(String.format(Sys.Res.cannotCallBeforeResponse, 'get_responseData'));
}
if (!this._xmlHttpRequest) {
throw Error.invalidOperation(String.format(Sys.Res.cannotCallOutsideHandler, 'get_responseData'));
}

var content=this._xmlHttpRequest.responseText;

// this is the added code, the rest is taken
// from the ASP.Net Ajax original code
var index=content.lastIndexOf('|');
if (index<content.length-1) 
content=content.substring(0,index+1);


return content;
}
}";

ScriptManager.RegisterStartupScript(Page,
  Page.GetType(), "adMurderer", script, true);
}

and has 12 comments
Update: I've posted the source and binaries for this control on Github. Free to use and change. Please comment on it.

This is the story of a control that shrinks the content sent from an UpdatePanel to down as 2% without using compression algorithms. I am willing to share the code with whoever wants it and I only ask in return to tell me if and where it went wrong so I can find a solution. Even if you are not interested in the control, the article describes a little about the inner workings of the ASP.Net Ajax mechanism.

You know the UpdatePanel, the control that updates its content asynchronously in ASP.Net, allowing you to easily transform a normal postback based application in a fully fledged Ajax app. Well, the only problem with that control is that you have to either put a lot of them on the page in order to update only what changes (making the site be also fast as you would expect from an Ajax application) but hard to maintain afterwards, or put a big UpdatePanel on the entire page (maybe in the MasterPage) and allow for large chunks of data to be passed back and forth and also other clear disadvantages, some detailed in this blog entry.

Not anymore! I have made a small class, in the form of a Response.Filter, that caches the previously rendered content and instructs the browser to do the same, then sends only a small fraction of the data from the server to the browser, mainly what has changed. There is still the issue of the speed it takes the browser to render the content, which is the same no matter what I do, like when rendering a huge table. It doesn't matter that I send only the changes in one cell, the browser must still render the huge grid. Also, if, for some reason, the update fails, I catch it and I send to the server that the updatepanel must be updated again, the old way.

Enough; let's talk code. I first had to tap into the content that was sent to the browser. That can only be done at Page render level (or PageAdapter, or Response.Filter and other things that can access the rendered content). So I did catch the rendered content in a filter, I recognized it as Ajax by its distinctive format, and I only processed the updatePanel type of token.

Here I had a few problems. First I replaced the updatePanel token with a scriptBlock token that changed the innerHTML of the update panel div element. It all seemed to work until I tested it a little. I discovered that the _updatePanel javascript method of the PageRequestManager object used by the normal ajax rendering on the browser was doing a few extra things, so I used that one instead of just replacing the innerHTML, resulting in a lower speed. But that didn't help either, because it failed when using validators. Even if I did replace the updatePanel token with a correct javascript block, it still got executed a bit later than it should have.

The only solution I had was to replace the _updatePanel method with my own. Itself having a small block of code that disposed some scriptblocks and some other stuff, then a plain innerHTML replace, I could not 'override' it, since it would change the innerHTML with some meaningless stuff (the thing I would send from the server), then I would parse and change the innerHTML again, resulting in bad performance, flickering, nonsense on screen, etc. So I just copy pasted the first part and added my own ApplyPatch function instead of the html replace code line.

Now, here I met another issue. The innerHTML property of an html element is not a simple string. It gets parsed immediately when set and it recreates when read, as explained in this previous article of mine. The only solution for that was create my own property of the update panel div element that remembers the string that was set. This solved a lot more problems, because it meant I could identify the content to be replaced by simple position markers rather than through regular expressions (as was my initial idea). That property would not get changed by custom local javascript either, so I was safe to use it.

About the regular expression engine in Javascript: it has no Singleline option. That means you can only change the content line by line. I could have used Steve Levithan's beautiful work, but with the solution found above, I would not need regular expressions at all.

The only other issue was with UpdatePanels inside UpdatePanels. I found out that in this case, only parent UpdatePanels are being rendered. That meant that the custom property I added to the child panel would disappear and break my code. Therefore I had to keep a tree of the updatepanels in the page and clear all the children cached content when the parents were being updated. So I did that, too.

What else? What if somehow the property would get deleted, changed, or something else happened, like someone decided to recreate the update panel div object or something like that? For that I made a little HttpHandler that would receive an UpdatePanel id and it would clear its cached content. Then, on return from the asynchronous call, the javascript would just push another update panel refresh using __doPostBack(updatePanelId,""). I don't particularily like this approach, since it could back fire with multiple UpdatePanels (as you know, only one postback at a time is supported), but I didn't find a better solution yet. Besides, this event should normally not happen.

So, the mechanism was all in place, all I had to do was make the actual patching mechanism, the one that would find the difference between previously rendered content and current content, then send only the changed part. First thing I did was remove the start and end of the strings that were identical. As you can imagine, that's the most common scenario: a change in the UpdatePanel means all the content up to the change remains unchanged and the same goes for the content after the change. But I was testing the filter with a large grid that would randomly change one cell to a random string. That meant two changes: the previous position and the last. Assuming the first change was in one of the starting cells and the last was in one of the cells at the end, then the compression would be meaningless. So I've googled for an algorithm that would give me the difference between two files/strings and I found Diff! Well, I knew about it so I actually googled for Diff :) It was in the Longest Common Substring algorithm category.

Anyway, the algorithm was nice, clear, explained, with code, perfect for what I wanted and completely useless, since it needed an array of m*n to get what I needed. It was slow, a complete memory hog and I couldn't possibly use an array of 500000x500000. I bet they were optimizations that covered this problem, but I was miserable so I just patched up my own messy algorithm. What would it do? It would randomly select a 100 characters long string from the current content and search for it in the previous content. If it found it, it would expand the selection and consider it a Reasonably Long Common Substring and work from then on recursively. If it didn't find it, it would search a few times other randomly chosen strings then give up. Well, actually is the same algorithm, made messy and with no extra memory requirements.

It worked far better than I had expected, even if it clearly could have used some optimizations. The code was clear enough in detriment of speed, but it still worked acceptably fast, with no noticeable overhead. After a few tweaks and fixes, the class was ready. I've tested it on a project we are working on, a big project, with some complex pages, it worked like a charm.

One particular page used a control I have made that allows for grid rows and columns to have children that can be shown/hidden at will. When collapsing a column (that means that every row gets some cells removed) the compressed size was still above 50% in up to 100 patch fragments. When colapsing a row, meaning some content from the middle of the grid would just vanish, the size went down to 2%! Of course, putting the ViewState into the session also helped. Gzip compression on the server would complement this nicely, shrinking the output even more.

So, I have demonstrated incredible compression of UpdatePanel content sent through the network with something as small and reusable as a response filter that can be added once in the master page. You could use it for customers that have network bandwidth issues or for sites that pay for sent out content. It would with sites made with one big UpdatePanel placed in the MasterPage as well :).

If you want to use it in your sites, please let me know how it performs and what problems you've encountered.