Sankofa

ASP.NET Migration Problem

If you’ve read my previous blog post, I talked about some of the problems encountered while migrating some of our web applications from .NET 1.1 to .NET 2.0. Well, those products are now handed off to the Test Department for their routine torture.

Just a couple of days after the hand-off (Hand-off to Test or HOTT), the tester who is testing the product filed two (2) Tracks (Incident/Bug/Problem). Since I am the only developer working on the product, all of the tracks will automatically be assigned to me. The said tracks that were filed have the same “type” of problem.

When browsing for a file (Backup File / File Upload), the value of the Textbox would change back to its default value when the page re-loads.

The web application that I am supporting was originally written in .NET 1.1 using Visual Studio 2003. To migrate it to .NET 2.0, we converted the solutions to VS2005. Aside from some minor problems like RESX incompatibility and broken Calendar Controls, the Web Application worked — I thought it did.

We have a Backup Restoration Page to allow the user to restore the web application in-case of Armageddon-like circumstances. The said page basically contain 3 components:

1. A Read-Only Textbox that holds the path of the Backup File . This Textbox has a default value of C:\Backups\Backup.bak
2. A Browse button that will launch a custom page that will allow the user to browse for the Backup File. The value selected there will be posted-back to the Backup Restoration Page.
3. A “Restore” button to start the restoration process.

When I tried to repro (reproduce) the bug on my Virtual Machine setup, I was able to verify that the path of the Backup File is losing its value on postback. To put it more precisely, the Textbox is not retaining the correct path since it is changing back to its default value on postback.

After hours of debugging, I was no where close in determining the cause of the problem. So I did a quick search on Google and found out that this is a common problem during migration from ASP.NET 1.1 to ASP.NET 2.0.

The problem is that Microsoft changed the behavior of read-only textboxes on ASP.NET 2.0.

ASP.NET 2.0 had a design change by which a control if marked with its ReadOnly property as true, would ignore client side changes and would lose the same across postback. So if you tried modifying the text box value or add a value to the text box using Javascript you wouldnt be able to retireve the value in the code behind or simply the value will be lost across postback.

This behaviour is by design in ASP.NET 2.0 and it has been designed with the idea that a ReadOnly TextBox shouldnt be modified in the client side by a malicious code.

Microsoft has a point. What’s the point of using a Textbox if you’re going to set it to Read-Only? Why not use a Label instead?

Fortunately, we have three simple workarounds for this problem.

1. Use a Label instead of a Read-Only Textbox. (Heard of Borders?)
2. Set the Read-Only property of the Textbox to FALSE (If you don’t really need the Read-Only Property)
3. But if you are really insisting of using a Read-Only Textbox, then we need to “fool” ASP.NET that the Textbox is not Read-Only even if it is.

To “fool” ASP.NET, you need to set the Read-Only property of the Textbox to FALSE during design time (Using the Property Pane) then set it to Read-Only on Page Load during runtime. You CANNOT use Textbox1.ReadOnly = true. You need to set the read-only attribute using the Attribute.Add() method.

// This is part of the C# code-behind file.
protected void Page_Load(object sender, EventArgs e)
{
     TextBox1.Attributes.Add("readonly", "readonly");
}

That will solve your postback problems.

References:

• http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.textbox.readonly.aspx
• http://www.dotnetspider.com/resources/3120-ASP-NET–TextBox-Ready-Only-losing-client-side-changes-values-across-postback.aspx
• http://stackoverflow.com/questions/856838/migration-asp-net-1-1-to-asp-net-2-0-broken-postback