Usually when I blog something I am writing the problem and the solution I have found. In this case, based also on the lack of pages describing the same problem, I have decided to blog about the problem only. If you guys find the solution, please let me know. I will post it here as soon as I find it myself. So here it is:

We started creating some tests for one of our web applications. My colleague created the tests, amongst them one that does a simple file upload. She used the following code:

var fu = ie.FileUpload(Find.ByName("ctl00$ContentPlaceHolder1$tcContent$tpAddItem$uplGalleryItem$fuGalleryItem"));
fu.Set(UploadImageFile);

and it worked perfectly. She was using WatiN 1.2.4 and MBUnit 2.4.

I had Watin 2.0 installed and MBUnit 3.0. Downloaded the tests, removed the ApartmentState thing that seems not to be necessary in MBUnit 3.0, ran them.
On my computer the FileUpload Set method opens a file upload dialog and stops. I've tried a lot of code variants, to no avail; I've uninstalled both MBUnit and WatiN and installed the 1.2.4 and 2.4 versions. Tried all possible combinations actually, using .NET 1.1 and 2.0 libraries and changing the code. Nothing helped. On my computer the setting of the file name doesn't work.

I've examined the WatiN source and I've noticed that it used a FileUploadDialogHandler that determines if a window is a file upload window or not by checking a Style property. I have no idea if that is the correct solution, but just to be sure I inherited my own class from FileUploadDialogHandler and I've instructed it to throw an exception with a message containing the style of the first window it handles. The exception never fired, so I am inclined to believe that the handler mechanism somehow fails on my computer!

I have no idea what to do. I have a Windows XP SP3 with the latest updates and I am running these tests in Visual Studio 2008 Professional.

Update:
The only possible explanation left to me is that Internet Explorer 8 is the culprit, since my colleagues all have IE7. The maker of WatiN himself declared that identifying the windows by style is not the most elegant method possible, but he had no other way of doing it. My suspicion is that the window handling doesn't work at all in IE8, but I have no proof for it and so far I have found no solution for this problem.

I've stumbled upon a little VS2008 addon that I think could prove very useful. It's called Clone Detective. Here is how you use it:

• Make sure VS2008 is closed
• Download and install the setup file
• Additionally the source is freely available!
• Open VS2008 and load a solution up
• Go to View -> Other Windows -> Clone Explorer
• Click the Run Clone Detective button

Now you should be able to see the percentage of cloned code in each file and also see the cloned code as vertical lines on the right vertical border next to the code.

Also, you might get a Sys.WebForms.PageRequestManagerServerErrorException with code 500 when using Ajax. It usually happends when you click on a button in a GridView or another bound control. You expect it to work, but it doesn't, even if the code is relatively clear.

The answer is (probably) that you are binding the container bound control every time you load the page (instead of only on !IsPostBack). The thing is this used to work in ASP.Net 2.0.

Bottom line: check your binding, see if you are not doing any DataBind in between the button click and the eventual event catch.

We started our first ASP.Net 3.5 project and today I had to work with the Linq database access. Heralded by many as a complete revolution in the way of doing ORM, LInQ is not that simple to move to. A lot of stuff that has become second nature for me as a programmer now must be thrown in the garbage bin.

I'll skip the "how to do LInQ" (there are far too many tutorials on the net already) and get down to the problem. Let me give you a simple example. You want to select a User from the Users table. Let's see how I would have done it until now:

User u=User.SelectById(idUser);

or maybe

User u=new User(); u.IdUser=idUser;
u.SelectOne();

In LInQ you do it like this:

var c=new MyDataContext();
User user=(from u in users where u.idUser=idUser select u).FirstOrDefault();

or maybe

var c=new MyDataContext();
User user=c.Users.Select(u=>u.IdUser=idUser).FirstOrDefault();

I am typing this by hand, forgive me the occasional typos or syntax errors.

Well, my eyes scream for an encapsulation of this into the User class. We'll do that by creating a new User.cs file that contains a User partial class that will just mold on the LInQ generated one, then adding methods like SelectById.

Ok, I have the bloody user. I want to change something, let's say rename him or changing the password, then save the changes to the database. Here it gets tricky.

User u=User.SelectById(idUser);
u.Password="New Password";
....?!

In LInQ you need to do a DataContext.SubmitChanges(); but since I encapsulated the select functionality in the User class, I have no reference to the DataContext. Now here are a few solutions for doing this without saving the linq queries in the interface:

1. Add the methods to the context class itself, stuff like SelectUserById();. You would still need to instantiate the DataContext though, in every query
2. Add a second out or ref parameter to the methods so that you can get a reference to the DataContext used.
3. Make a method for each operation, like User.SetPasswordById();, that would become quickly quite cumbersome.
4. Add a reference to the DataContext in the User object, but that would become troublesome for operations like SelectAll

.

I am still not satisfied with any of these solutions. I am open to suggestions. I will link to this little article I found that suggests encapsulating the LInQ queries in separate extensions methods: Implementing ORM-independent Linq queries

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.

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.

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!

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;
 }

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.

This post will be quite lengthy and it will detail my findings on best practices with SQL, specifically Microsoft SQL Server.

I started with an article written by Vyas Kondreddi in 2001: SQL Server TSQL Coding Conventions, Best Practices, and Programming Guidelines. In 2001 people were not microblogging!

Well, to summarize the article and bring it up to date a little, here are some of the most important points (in my view):

• Decide upon a database naming convention, standardize it across your organization, and be consistent in following it. It helps make your code more readable and understandable.
• Write comments in your stored procedures, triggers and SQL batches generously, whenever something is not very obvious.
• Try to avoid server side cursors as much as possible.
  As Vyas Kondreddi himself says: "I have personally tested and concluded that a WHILE loop is always faster than a cursor"
• Avoid the creation of temporary tables while processing data as much as possible, as creating a temporary table means more disk I/O. Consider using advanced SQL, views, SQL Server 2000 table variable, or derived tables, instead of temporary tables.
  This is interesting, because I usually use a lot of temporary tables in my stored procedures to make the code more orderly. I guess that in the case of SQL Server 2005 and later one can always use Common Table Expressions to make the code more readable. For SQL 2000 and such I found two interesting articles about not using temporary tables and replacing them with either derived tables (selects in selects) or with table variables, although they do have some limitations, thoroughly explained in the latter post. Here are the links: Eliminate the Use of Temporary Tables For HUGE Performance Gains and Should I use a #temp table or a @table variable?
• Try to avoid wildcard characters at the beginning of a word while searching using the LIKE keyword, as that results in an index scan, which defeats the purpose of an index.
  For a short analysis of index scans go to SQL SERVER - Index Seek Vs. Index Scan (Table Scan).
• Use the graphical execution plan in Query Analyzer or SHOWPLAN_TEXT or SHOWPLAN_ALL commands to analyze your queries.
• Use SET NOCOUNT ON at the beginning of your SQL batches, stored procedures and triggers in production environments, as this suppresses messages like '(1 row(s) affected)' after executing INSERT, UPDATE, DELETE and SELECT statements. This improves the performance of stored procedures by reducing network traffic.
• Use the more readable ANSI-Standard Join clauses instead of the old style joins.
• Incorporate your frequently required, complicated joins and calculations into a view so that you don't have to repeat those joins/calculations in all your queries.
• Use User Defined Datatypes if a particular column repeats in a lot of your tables, so that the datatype of that column is consistent across all your tables.
  Here is a great article about Sql UDTs (not the new .NET CLR types): What's the Point of [SQL Server] User-Defined Types?. Never used them, myself, but then again I am not an SQL guy. For me it seems easier to control data from .Net code
• Do not let your front-end applications query/manipulate the data directly using SELECT or INSERT/UPDATE/DELETE statements. Instead, create stored procedures, and let your applications access these stored procedures.
  I am afraid I also fail at this point. I don't use stored procedures for simple actions like selecting a specific item or deleting a row. Many time I have to build search pages with lots of parameters and I find it really difficult to add a variable number of parameters to a stored procedure. For example a string that I have to split by spaces and search for all found words. Would it be worth to use a stored procedure in such a situation?
• Avoid dynamic SQL statements as much as possible. Dynamic SQL tends to be slower than static SQL, as SQL Server must generate an execution plan every time at runtime.
  Personally, I never use dynamic SQL. If I need to create an SQL string I do it from .Net code, not from SQL.
• Consider the following drawbacks before using the IDENTITY property for generating primary keys. IDENTITY is very much SQL Server specific, and you will have problems porting your database application to some other RDBMS. IDENTITY columns have other inherent problems. For example, IDENTITY columns can run out of numbers at some point, depending on the data type selected; numbers can't be reused automatically, after deleting rows; and replication and IDENTITY columns don't always get along well.
  So, come up with an algorithm to generate a primary key in the front-end or from within the inserting stored procedure. There still could be issues with generating your own primary keys too, like concurrency while generating the key, or running out of values. So, consider both options and go with the one that suits you best.
  This is interesting because I always use identity columns for primary keys. I don't think a data export or a database engine change justify creating a custom identity system. However I do have to agree that in the case that data is somehow corrupted a GUID or some other identifier would be more useful. I am sticking with my IDENTITY columns for now.
• Use Unicode datatypes, like NCHAR, NVARCHAR, or NTEXT.
• Perform all your referential integrity checks and data validations using constraints (foreign key and check constraints) instead of triggers, as they are faster.
• Always access tables in the same order in all your stored procedures and triggers consistently. This helps in avoiding deadlocks. Other things to keep in mind to avoid deadlocks are: Keep your transactions as short as possible. Touch as few data as possible during a transaction. Never, ever wait for user input in the middle of a transaction. Do not use higher level locking hints or restrictive isolation levels unless they are absolutely needed. Make your front-end applications deadlock-intelligent, that is, these applications should be able to resubmit the transaction incase the previous transaction fails with error 1205. In your applications, process all the results returned by SQL Server immediately so that the locks on the processed rows are released, hence no blocking.
  I don't have much experience with transactions. Even if I would need transactions in some complex scenarios, I would probably use the .Net transaction system.
• Offload tasks, like string manipulations, concatenations, row numbering, case conversions, type conversions etc., to the front-end applications.
  Totally agree, except the row numbering, where SQL 2005 added all those nice Getting the index or rank of rows in SQL Server 2005 aggregate ranking options
• Always add a @Debug parameter to your stored procedures. This can be of BIT data type. When a 1 is passed for this parameter, print all the intermediate results, variable contents using SELECT or PRINT statements and when 0 is passed do not print anything. This helps in quick debugging stored procedures, as you don't have to add and remove these PRINT/SELECT statements before and after troubleshooting problems.
  Interesting, I may investigate this further, although the SQL debugging methods have improved significantly since the article was written.
• Make sure your stored procedures always return a value indicating their status. Standardize on the return values of stored procedures for success and failures. The RETURN statement is meant for returning the execution status only, but not data. If you need to return data, use OUTPUT parameters
• If your stored procedure always returns a single row resultset, consider returning the resultset using OUTPUT parameters instead of a SELECT statement, as ADO handles output parameters faster than resultsets returned by SELECT statements.
• Though T-SQL has no concept of constants (like the ones in the C language), variables can serve the same purpose. Using variables instead of constant values within your queries improves readability and maintainability of your code.

The next stop was SQL Server Best Practices from Microsoft.

Here are the articles I found most important, covering stuff from testing the I/O system of the system you want to install SQL server to up to Database backup, mirroring and maintainance:
Predeployment I/O Best Practices
SQL Server 2005 Deployment Guidance for Web Hosting Environments
SQL Server 2005 Security Best Practices - Operational and Administrative Tasks
Comparing Tables Organized with Clustered Indexes versus Heaps
Troubleshooting Performance Problems in SQL Server 2005
Implementing Application Failover with Database Mirroring
SQL Server 2005 Waits and Queues
TEMPDB Capacity Planning and Concurrency Considerations for Index Create and Rebuild
The Impact of Changing Collations and of Changing Data Types from Non-Unicode to Unicode
XML Best Practices for Microsoft SQL Server 2005
Performance Optimizations for the XML Data Type in SQL Server 2005
Top 10 Hidden Gems in SQL Server 2005

Lastly some links that I will not go in depth on:

SQL Server 2000 Best Practices
SQL SERVER - 2005 Best Practices Analyzer Tutorial - Sample Example describes the Microsoft Best Practices Analyser application. I tried it myself, it's not much. It touches mainly on the maintainance and security issues that I don't really concern myself with.
Top 10 Best Practices for Building a Large Scale Relational Data Warehouse. I don't think I will need it soon, but it is a short and interesting read.
SQL Server Pre-Code Review Tips. This Pinal Dave guy is pretty cool. He seems like a good resource for SQL related issues.
CMS Database Administration SQL Server Standards, a set of SQL coding standards for a medical government agency.

I am sure there are a lot of interesting resources on the net. I will update this post with new information once I get to it.

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.

It was great! Not only the setting was nice (the four star Smart hotel is exactly what I had expected a hotel should be, except the restaurant, maybe), but the weather was cool, the presentation helpful, the tutor (Aurelian Popa) was above expectations and the people pleasant. Not to mention a week away from boring stuff. ;) I feel it would be pointless to detail what we did there, since it was either my own personal life or the actual workshop (which involves work), so I will give you some impressions of the technology and point you towards the resources that would allow you to go through the same learning process.

The whole thing was about WPF and SilverLight and I can tell you two conclusions right now:
WPF/XAML/SilverLight are a great technology and I expect a lot of .Net applications to migrate towards it in the next 6 to 12 months.
The complexity of this technology is likely to put a lot of people off, therefore the tools like Expression Blend and the Visul Studio interface become completely indispensable and must evolve to have great ease of use and become more intuitive.

The entire presentation model allows one to use any graphical transformation available, including 3D, on any part of the interface. The controls are now without appearance. They come with a default appearance that can be totally replaced with your own. A weird example is to use a 3D cube with video running on each side as a button. Of course, the whole thing is still work in progress and some stuff is yet difficult to do. Besides, you know Microsoft: a lot of complicated things are easy to do, while some of the simplest are next to impossible.

You can taste the Microsoft confidence on this by watching them release an entire design oriented suite (Expression) and working on making Silverlight available on all platforms and browsers. Just the fact that Silverlight can access directly the browser DOM is enough to make me remove all those patchy javascript scripts and replace them with nice Silverlight C# code.

Enough of this. Go learn for yourself!

Tools:
Silverlight is at version 2 beta 2. That is painfully obvious when new bugs are introduced and beta 1 applications break. The Expression Blend tool is at version 2.5 June 2008 CTP and it has also a long walk ahead towards becoming useful. Visual Studio 2008 performs rather well when faced with XAML and WPF stuff, but the Resharper 4.0 addon helps it out a lot. You need the Visual Studio 2008 Silverlight Tools, too. After this compulsory tool kit you could also look at Snoop, Blender and Expression Deep Zoom Composer.

Learning material:
Simplest thing to do is to go to Silverlight Hands-on Labs or download the WPF Hand-on labs and download them all and run through the documentation script that is included with each one. There are video tutorials about how to use the tools, too. Here is one for Blend. Of course, all blogs and materials available online at the search of a Google are helpful, as well.

Community:
As any community, it depends on your desired locality and interests. You can look for local .Net / WPF groups or browse for blogs half way around the globe from you. From my limited googling during the workshop I can see that there are people talking about their issues with WPF and SL, but not nearly enough: the technology still needs to mature. I haven't really searched for it, but I've stumbled upon this site: WindowsClient.NET that seems to centralize WPF, Windows Forms and a bit of Silverlight information.

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.

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.

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.