Category: JavaScript

HTML Web Resource in CRM

In Microsoft Dynamics CRM HTML web resource we have Xrm.Page.context parameter from where you can get different information about your CRM/Page etc…


This gives an impression that we will have access to all other XRM scripting properties like etc… but that is not the case.

I was having requirement to get the record ID and found given msdn document. Which tells you can pass the records as parameters.

How to Do It:

Go to Web resource Properties in form Editor, Select given check box.


You will be able to get the record id in URL.

Pre Check Box Checked


Post Check Box Checked (there is a whole lot of stuff as given in msdn)


Fetching Data from Query String GetQueryString(“id”) will give you the record id. Similarly you can fetch other values as well.

[code language=”javascript”]
function GetQueryString(key) {
var resourceUrl = document.location.href;
var queryList = resourceUrl.split(/[?&]+/);
for (i = 0; i < queryList.length; i++) {
pair = queryList[i].split("=");
if (pair[0] == key) {
return pair[1];

Confusing Closures made Simple


Closure is one of the trickiest concept of functional programming and all languages that have “first-class functions” support closures.

Closure by literal definition is “The act of closing” or “The state of being closed”

Have a look at function below:

[sourcecode language=”javascript”]

function OuterFunction(outerVariable)
var InnerFunction= function(innerVariable)
alert(‘I still remember Outer Variable : ‘+outerVariable +’ when you passed Inner Variable : ‘+innerVariable);
return InnerFunction;

var returnFunction = OuterFunction(‘Yahoo!’);


Now when we make a call to returnFunctions(‘bing’); output will be


Even though ‘OuterFunction’ has executed and returned ‘InnerFunction’ the value of ‘outerVariable’ is still there in the memory.

‘returnFunction’ will always contain the value of ‘outerVariable’ as ‘Yahoo!’ and it is a closure over the ‘outerVariable’.

Floating Point Calculation Error

In a blog post I read somewhere that if you give alert(9.2*100); in JavaScript then the alert box will show 919.999999999999 instead of 920.

Many people wonder, “Why is it so?”, “Is it a bug?”

Answer to question “Is it a Bug?” is Yes and No.

Yes, because you are getting wrong output and a general definition of bug is “software bug is an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.”

No, because this is the way floating point calculations have been designed and this is what has been standardized by IEEE in IEEE 754 standard. Similar behavior you will see in 8.2*100, .1+.2 etc…

To Understand “Why is it so?”

The behavior we are seeing is because underneath calculations are done in Binary not in Decimal and the languages which don’t handle rounding off of numbers show this behavior.

Let’s have a look at this calculation

9.2 * 100 = 1001.? * 1100100

Converting .2 into Binary

.2 * 2 = 0.4 – 0

.4 *2 = 0.8 – 0

.8*2 = 1.6 – 1

.6*2 = 1.2 – 1


So number is – 00110011……(an infinite chain)

Calculating back to Decimal: to show that we are not taking huge precision and it will impact final result

2^(-1) *0+ 2^(-2)*0+2^(-3) *1+ 2^(-4)*1 +2^(-5) *0+ 2^(-6)*0+2^(-7) *1+ 2^(-8)*1

= (.5)*0+(.25)*0+(.125)*1+(.0625)*1+(.03125)*0+(.015625)*0+(.0078125)*1+(.00390625)*1

= 0+0+.125+.0625+0+0+.0078125+.00390625

= 0.19921875


Now 9.2 is 1001.00110011….

Or Take it as 100100110011 after incorporating shift (2^8)

Now 100100110011 * 1100100 = 111001011111101100 (Done in Programmer Calculator J)

Incorporating Shift


= 919

= .5+.25+.125+0+.03125+.015625+0+0…………………

= 0.921875

So 1110010111.11101100 is 919.921875

If we would have taken a longer chain of.2 i.e. we would have taken 00110011001100110011001100110011001100110011001100110 it would have given a more precise result of 919.99999999999999

To read more about floating point errors you can check these links.