ASP.NET Ajax - Number.format doesn't round

I recently came across an annoying inconsistency between Decimal.ToString()/String.Format() on the server, and Number.format()/Number.localeFormat() on the client javascript. The client code doesn't round!

Try it yourself. Open firebug on an ASP.NET Ajax website (this one will do), open the Console, and type

123.456.format("N2")

This simple line of code tells it to format the string as a decimal to 2 decimal places. The resulting output, 123.45, is WRONG!

Try this using .NET on the server 123.456.ToString("N2") and you will get the correctly rounded value - 123.46.

How to fix this? As I have pointed out before, with JavaScript, you can override any function by just defining it later on in the HTML. So I created a new script file with a new definition of the Number._toFormattedString() method, which is the private method used to do the formatting. I then include this file in the <scripts> of my ScriptManager on the master page. Script references are always loaded after ASP.NET Ajax internal scripts itself.

It's not that hard to fix - you just have to apply some rounding logic to the existing code, which features the following line:

if (rightDifference > 0) {

  right = right.slice(0, precision);

}

This just slices the end of the string off and doesn't even consider doing any rounding!

Now there are many ways to perform rounding which I won't go into here, but if you want to check it you can download the replacement script here. Simply include this in an <asp:scriptreference> in the scripts section of your script manager and rounding should work fine.

Hope this helps.

SharePoint - dragging WebParts causes "object required" Javascript error

I have been working with SharePoint quite a bit over the past few months. At Netstore we are building an AA accessible website for our client using XHTML with a CSS based layout.

I recently came across a problem where I had a WebPartZone in a page, and when I tried to drag the webparts around I get the javascript error "Object Required". Fortunately, a bit of googling led me to this post - CSS causes JavaScript error while moving Web Parts in edit mode where I learned the issue is due to the zones being placed in elements with a CSS style of position:relative.

Unfortunately I had to fix the bug to pass UAT so I was left with two options - either change the CSS to remove the relative positioning or try to fix the JavaScript. Given that we were working with HTML/CSS delivered by an external design agency (which I didn't want to mess with) I decided to go with the latter.

The blog entry indicated that the problem lay in a Microsoft function called MSOLayout_GetRealOffset. This function is defined in <12>\TEMPLATE\LAYOUTS\1033\IE55UP.JS. I didn' t fancy changing this file as it would present a deployment nightmare, but fortunately with JavaScript, you can override a global function by just defining it later on in the HTML. Therefore I was able to redefine this function in my master page and fix the error. Here is the new version of the function:

        <script language="javascript" type="text/javascript">

            function MSOLayout_GetRealOffset(StartingObject, OffsetType, EndParent)

            {

                var realValue=0;

                if (!EndParent) EndParent=document.body;

                for (var currentObject=StartingObject; currentObject && currentObject !=EndParent && currentObject != document.body; currentObject=currentObject.offsetParent)

                {

                    var offset = eval('currentObject.offset'+OffsetType);

                    if (offset) realValue+=offset;

                }

                return realValue;

            }

        </script>

So if you ever experience the problem, copy and paste this function into your master page file, anywhere after the SPWebPartManager and it should stop.