Blog Home  Home Feed your aggregator (RSS 2.0)  
How to fix the most annoying ASP.NET 2.0 bug (TreeView XHTML compliance) - Manuel Abadia's ASP.NET stuff
# Thursday, October 25, 2007

Or at least, one of them.

If you have used the TreeView control in ASP.NET and tried to validate your page against XHTML 1.0 transitional you’ll have the unpleasant surprise to see that the TreeView does not produce compliant code because of this:



    function TreeView_PopulateNodeDoCallBack(context,param) {



// -->



The generated script code does not have the required type='text/javascript' attribute.

It is sad that Microsoft didn’t find this bug out before releasing 2.0. They should work with something like this xhtml validation module when testing their controls. The fix for this problem is trivial, just add the type attribute to the injected script and everybody is happy.

However, this is one of the cases that really annoy people. For some “never to be understood” reason, Microsoft closed this bug as “Won’t fix”. I can’t give you the link to the bug report as Microsoft Connect is not working for the last 2 days.

You can use the CSS Control Adapter to fix this, or use a third party TreeView. However, that is no excuse to not having this bug fixed. I can understand that they don’t fix bugs like the poor extensibility of the ParameterCollectionEditor as there is a lot of work (however, even if I understand that, I think that it should be fixed. If it is a lot of work is because of bad design. If it has been designed with extensibility in mind things like this will not happen as often) but this trivial bug to fix has no excuse.

Yesterday I faced against this bug again and was too angry to be able to keep working without doing anything about it. I used reflector to see if there was any way to fix the bug without having to recreate the full TreeView class and I was lucky.

The TreeView uses IsClientScriptBlockRegistered and RegisterClientScriptBlock to register the invalid script code, so registering a valid script code before has to work, and indeed it does:

using System;

using System.Web.UI;

using System.Web.UI.WebControls;


namespace Manu.Web.UI.WebControls


    /// <summary>A TreeView that fixes the most annoying ASP.NET 2.0 bug ever!.</summary>

    public class FixedTreeView : TreeView


        #region Fields


        protected static string populateNodeScript = "\r\n<script type='text/javascript'>\r\n<!--\r\n    function TreeView_PopulateNodeDoCallBack(context,param) {\r\n        ";

        protected static string populateNodeScriptEnd = ";\r\n    }\r\n// -->\r\n</script>\r\n";




        #region Methods


        /// <summary>Raises the PreRender event.</summary>

        /// <param name="e">An System.EventArgs that contains event data.</param>

        protected override void OnPreRender(EventArgs e)


            ClientScriptManager clientScript = Page.ClientScript;


            // register a correct script code before the TreeView

            if (!clientScript.IsClientScriptBlockRegistered(base.GetType(), "PopulateNode"))


                clientScript.RegisterClientScriptBlock(base.GetType(), "PopulateNode", populateNodeScript + clientScript.GetCallbackEventReference("", "param", "TreeView_ProcessNodeData", "context", "TreeView_ProcessNodeData", false) + populateNodeScriptEnd);



            // do the original processing








It is sad to have to resort to this even in the next ASP.NET version. Hopefully a Microsoft guy can fix this in time for the next ASP.NET version.


Thursday, October 25, 2007 9:38:14 AM (Romance Daylight Time, UTC+02:00)  #    Comments [1]   ASP.NET | XHTML  | 
Copyright © 2020 Manuel Abadia. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.