With Dynamics CRM 2011, the Label property is required:

This is not a problem until you attempt to edit the properties of an IFRAME. If the Label is blank, you will receive and error and be forced to complete the field.

Not a huge deal, but something you will have to correct when you may not have been expecting it.

The CRM 2011 SDK documents this process here:

Open Forms, Views, Dialogs and Reports with a URL?

It also includes a very important note:

Do not use the etc (entity type code) parameter that contains an integer code for the entity. This integer code varies for custom entities in different organizations.

One of the required parameters on a Dynamics CRM URL is the type of entity you’re opening. This is specified by one of these parameters:

• etc – for Entity Type Code
• etn – for Entity Type Name

In Dynamics CRM 4.0, (and 3.0 for that matter), most people used the etc parameter.  This cause some very bad side-effects when moving your code from installation to installation (development, test, production).  The Entity Type Code could, and often did, vary from installation to installation.

etn, the second parameter, allows you to specify the name of the entity: account, contact, new_entity, etc.  This information does not change from installation to installation.

Anecdotal Evidence:

I once saved 30 minutes per roll-out by switching all of my URL references from etc to etn. Before that, I had to hand-modify my code to reference the proper Entity Type Code and had to maintain an Excel worksheet with that information.

etn has been around since at least CRM 4.0 but you can save yourself a lot of trouble in the future, by converting your code from etc to etn.

Problems and Issues

I ran into an unexpected situation during an upgrade that quite honestly, left me a bit baffled. It seems a breaking change was introduced during the CRM 2011 upgrade process.

Some Background

In CRM 4.0, you could open an Entity record with either one of the following URLs:

http://crm2011/Contoso/userdefined/edit.aspx?id=%7bE50B1A7B-1AA2-E211-953E-00155D200507%7d&etn=new_entity

http://crm2011/Contoso/userdefined/edit.aspx?id=%7bE50B1A7B-1AA2-E211-953E-00155D200507%7d&etc=10010

The difference being using the parameter etn (entity type name) instead of etc (entity type code). Using etn is preferable because it causes fewer issues when migrating from one system to another (development, test, production).

This technique is used extensively in an xRM scenario where you may have additional web pages that use or reference CRM data. It is common to have a screen artifact, like a button, that will open a CRM record when pressed and the URLs listed above are what is used.

.

The Issue

It would seem that the etn parameter is no longer supported by the edit.aspx page in CRM 2011 for what appears to be custom entities only. It seems to work fine for out-of-the-box entities.

The Solution

The use of etn is ONLY supported on main.aspx, AND you need to specify the &pagetype=entityrecord parameter, like this:

http://crm2011/Contoso/main.aspx?etn=new_entity&id=%7bBB81247D-7494-E111-913F-00155D00650B%7d&pagetype=entityrecord

Further Confusion

I am sure you have noticed, and maybe used, the Copy a Link/Email a Link functionality built into CRM:

This is a very handy feature and I use it all of the time.

Unfortunately, it will return a different URL depending on the entity being used. Standard entities will produce a URL with main.aspx while custom entities will produce edit.aspx.

And again, only main.aspx can use the etn parameter.

Additional Reading

I cover this topic a little more in this article:

Upgrade Your URL Parameter References

and I’ll update that article to reflect this new information.

var lookupItem = new Array();
lookupItem[0] = new LookupControlItem("{3A6C1B06-C62F-DC11-AFC2-0019B9B20373}", 1, "A Sales Store 3");
crmForm.all.pricelevelid.DataValue = lookupItem;

This function still exists in Dynamics CRM 2011 but it is still unsupported and quite honestly, doesn’t look like it works correctly. This is mostly due to the fact that using the Object Type Code, or the numeric identifier for the Entity, has been deprecated and no longer functions as it once did.  In CRM 2011, you must use the Entity’s Name instead.

So, where does that leave us?  Fortunately, in a not so bad place.

You can add the following function to a JScript web resource, add the web resource to your form, and modify your code a little, and it will function as it always did.  Here is the new function:

function LookupControlItem2011(id, typeName, name)
{
    var lookupItem = new Object();

    lookupItem.id = id;
    lookupItem.entityType = typeName;
    lookupItem.name = name;

    return lookupItem;
}

It is used like this:

var lookupData = new Array();
lookupData[0] = LookupControlItem2011('{B1FC92B0-B305-E211-B881-00155D00650B}', "account", 'A Sales Store 3');

Xrm.Page.getAttribute("parentaccountid").setValue(lookupData);

Three things had to change, to make this work correctly:

1. Remove the new keyword from in front of LookupControlItem.

2. Rename LookupControlItem to LookupControlItem2011, which will prevent a conflict with the existing function.

3. Replace the 2nd parameter, which is an integer, with the schema name for the Entity.

As you can see from my examples, I replaced 1 with account.

Making these small changes will allow you to use your existing code with a minimum amount of effort.

I have seen several instances where code such as this:

if (crmForm.all.emailaddress1 != null)
{

    crmForm.all.emailaddress1.ondblclick = function ()
    {

        var email = crmForm.all.emailaddress1.DataValue;

        if ((email != null) && (email.length > 0))
        {
            window.navigate("mailto:" + email);
        }
    }
}

Has been added to turn an email-style text field into a hyperlink that will launch the user’s default email editor when clicked or double-clicked.

The code above is unnecessary because Dynamics CRM 2011 offers this feature by default so any instance of this code can be safely removed and the functionality will still exist.

This is not a huge deal, but it is one less piece of code that needs to be maintained.

The Situation

JavaScript doesn’t actually require you to insert a terminating semicolon. If you do not, the JavaScript runtime of the browser will insert one for you.

The Problem (in general)

Problems arise when the JavaScript runtime "guesses" incorrectly, inserts a semicolon where one is not supposed to be, and it alters the execution of your JavaScript.

The Cause

Sometimes this occurs due to an oversight on the part of the developer ( just plain didn’t type it in ).  Other times it is because the developer did not know any better.  A lot of CRM users who are new to JavaScript simply type in code and don’t understand the underlying reasoning behind it.  Finally, some JavaScript developers think a semicolon detracts from the code readability and don’t use semicolons for that reason.

Regardless, it can lead to problems.

The Problem (specific to the JavaScript conversion process)

The CRM JavaScript Conversion Assistant actually performs a Lexical Analysis of the JavaScript being converted.

During this "tokenization" process, semicolons are not actually inserted, but the locations where they should be are treated as if a semicolon existed so the tokens are properly generated. This, for the most part, works as you might expect, and in much the same way that a JavaScript runtime would.

Issues start to arise during the actual conversion process. As I mentioned, semicolons are not actually inserted into the token stream. This means that if the token conversion process is looking for a terminating semicolon, errors can be generated when one is not found.

In most cases we have constructed the token conversion process to take this situation into account, but there are probably edge cases where the code is written in such a way as to cause a conversion failure.

If you run into this situation, then please send us the code segment that is causing the issue and we’ll work to create a fix.

Conclusion

In general, when performing the conversion from CRM 4.0 to CRM 2011, it’s a perfect time to fix any code-design issues you might find.  So, keep an eye out for the missing semicolons and add them where required.

Further Information:

7.9.1 Rules of Automatic Semicolon Insertion

http://cjihrig.com/blog/the-dangers-of-javascripts-automatic-semicolon-insertion/

http://elegantcode.com/2011/01/12/basic-javascript-part-6-automatic-semicolon-insertion/

I’ve created a page so that you can view them without having to download the webinar support materials.

If you run into something that is not on either of these lists, I would really appreciate it if you could send me a code sample so I can research the conversion possibilities.

We’ll discussed the technical aspects of converting your JavaScript from CRM 4.0 to CRM 2011, as well as the processes that will aid in the overall upgrade process.

Tools to Help Your Conversion:

JavaScript Converter

http://dynamicsxrmtools.codeplex.com

CRM JavaScript Conversion Assistant

http://www.crmaccelerators.net/products/crm-migration-assistant-2

CRM Code Validation Tool

http://blogs.msdn.com/b/crm/archive/2012/06/21/microsoft-dynamics-crm-2011-custom-code-validation-tool-released.aspx

Export JavaScript

http://blogs.infinite-x.net/free-utilities

Export Web Resources

http://blogs.infinite-x.net/free-utilities

Web Resource Manager

http://jswebresourcemanager.codeplex.com

Conversion Keywords and Sample Conversions:

Here is the Excel worksheet discussed that the end of the presentation. It contains keywords that can be successfully converted as well as those that cannot.

Download

Download the trial version now or visit our product page for more information.

New Name

The product formally known as the CRM Migration Assistant has been renamed to the CRM JavaScript Conversion Assistant to more closely match its name with its functionality.

I am keeping the version number sequence the same.

New Price

The price has been reduced to $395 (from $495).

New Features

The following new features have been added:

Convert from CRM 2011

The most important feature added is the ability to connect to a CRM 2011 Organization and convert the existing JavaScript Web Resources.

The JavaScript can be uploaded back into CRM 2011 after you have finished the conversion process.

Conversion Alert Handling

The way conversion alerts are handled in the user interface has been enhanced. Any entity that contains conversion alerts is now highlighted in the event list:

The number of conversion alerts is displayed in the upper-right corner of the CRM 2011 window. This is actually a button. Clicking the button will cause the CRM 2011 editor to jump to the next Conversion Alert.

Markers have been placed in the left margin on lines that contain a Conversion Alert:

Next and Previous buttons have been added that allow you to jump to the next and previous Conversion Alert:

Improved Conversion Report

The Conversion Report has been modified and enhanced to provide a better view into the work that either has been performed by the conversion process or the work that will need to be provided. Here is how the Conversion Report is designed:

ROI

Provides a "guestimate" as to the amount of time and the CRM JavaScript Conversion Assistant saved you.

Conversion Alerts

Lists all of the conversion alerts found during the conversion process.

ActiveX Objects

Lists all ActiveX objects that were found, and their locations. This is good to know if you are planning to provide cross-browser support.

External Files

Any references to external files including: JavaScript, .ASPX, .CSS, and .ASMX

Object Locations

References to attributes and functions and where they can be found on the forms.

Duplicate Functions

This is a list of duplicate function names and where they can be found. Reduction of duplicate functions is one of the primary cleanup activities when you’re converting from CRM 4.0.

Duplicate Events

Events whose JavaScript exactly matches. Again, this is provided to help you reduce the amount of code you are writing and maintaining.

Event Summary

Lists the following information for each of the entities converted:

• Name
• Lines of Code
• Conversion Alerts report
• Conversions performed by the CRM JavaScript Conversion Assistant.

New Conversions

The conversion process has been enhanced and the following conversions have been added:

1. Added Conversion Alerts for the following keywords:

• AddBindingColumn
• AddDependentParameters
• AddItems
• AddOptionGroup
• allowblankdate
• AreValuesDifferent
• AttachDataSlugEvents
• attachEventHandler
• BuildXml
• BuildXmlToSubmitForm
• BypassValidation
• CreateInnerSlug
• crmTabBar
• CurrencyPrecision
• CurrencySymbol
• CurrentOperatorIsClear
• DataXml
• dblclick
• DeleteDataSlug
• DeleteDataSlug
• displayMissingValue
• DisplayValue
• fireSaveEvent
• FormatDuration
• GetDataXml
• GetInnerControl
• GetLabelControl
• GetLookupControl
• getLookupField
• GetLookupTypeIcon
• GetTab
• getTime
• GetXml
• IgnoreCurrencySymbol
• InitializeLookupPresence
• insertCell
• insertRow
• InsertSlugControl
• IsBaseCurrency
• IsMoney
• IsPermissibleType
• IsValid
• Items
• launchOnDemandWorkflowForm
• Lookup
• NO_DATA
• oncontextmenu
• onfocusin
• onfocusout
• onmouseenter
• onmouseleave
• ParseXml
• Print
• QueryLookupPresence
• RaiseOnAfterSelectEvent
• RaiseOnChange
• RaiseOnChangeEvent
• RaiseSetAdditionalParamsEvent
• RefreshLookupItemImage
• refreshTimeValue
• RemoveItem
• ResetDefault
• ResetToDefault
• RunReport
• SetAllFieldsToNonReqLevel
• SetCurrency
• SetDataSlugs
• SetTabFocus
• setTime
• Sort
• SortingEnum
• SubmitFormId
• swapNode
• TimeControl
• UpdateInnerHtml
• UpdateItem
• UpdateOperatorControl
• VerifyFieldIsSet
• Visible
• WillSubmit

Many of these came from information found in the Custom Code Validation Tool that Microsoft released a couple of weeks ago.

It should be noted that not all of these keywords identified in the Custom Code Validation Tool will be recognized by the CRM JavaScript Conversion Assistant. This is because the conversion process is verified by a series of unit tests ( 510 at the moment ) and I could not find code samples to verify the usage of the method or property. Since I could not find code, I could not write a test. Not test means no inclusion in the conversion process.

If you run into anything that I missed, please send me a code sample and I’ll get it added to the process as soon as I can.

2. Converted: crmForm.HideField(crmForm.all.lastname) to
                     Xrm.Page.getControl("lastname").setVisible(false)

3. crmForm.<attribute name>.Clear
 
This internal method was used to remove data from an attribute. The supported way to do this is Xrm.Page.getAttribute("<attribute name>").setValue(null);

4. Corrected conversion issues caused by improperly written JavaScript.

5. Added support for .defaultValue, which converts to setValue().

6. Any references to window.event.srcElement will automatically have
   the "window." qualifier removed.

7. Added a conversion alert when any hard-code GUID is found. For example:
lookupItem.id = ‘{45A34093-8731-DC11-A0C7-0019B9DE8282}’;
lookupItem.id = /* CONVERSION ALERT */’{45A34093-8731-DC11-A0C7-0019B9DE8282}’;

8. Added support for conversion alerts for:

• areaAccounts
• areaContacts
• areaAddresses
• areaOpps
• areaQuotes
• areaOrdersareaInvoices
• areaService
• areaContracts
• areaRelationships
• areaListsInSFA
• areaCampaignsInSFA
• areaCampaignsInListareaForm

9. .Click method handling:
   crmFrom.all.tab1Tab.click();
   Xrm.Page.ui.tabs.get(1).setFocus();

   document.getElementById(‘navAddresses’).click();
   Xrm.Page.ui.navigation.items.get("navAddresses").setFocus();

   All others produce a Conversion Alert.

10. crmForm.all.name.setAttribute("display", "none"); convers to:
       Xrm.Page.getControl("name").setVisible(false);

11. crmForm.all.name.Visible = true; converts to:
       Xrm.Page.getControl("name").setVisible(true);

12. innerText property handling:

       crmForm.all.tab2Tab.innerText = ‘Contacts’; converts to:
       Xrm.Page.ui.tabs.get(2).setLabel(‘Contacts’);

       document.getElementById(‘navActivityHistory’).innerText = "Closed History");
       Xrm.Page.ui.navigation.items.get("navActivityHistory").setLabel("Closed History"));

       crmForm.all.new_field.innerText = "My Label";
       Xrm.Page.getControl("new_field").setLabel("My Label");

       crmForm.document.title = titleElem.innerText;
       Xrm.Page.getAttribute("document")./* CONVERSION ALERT */title = titleElem.
          /* CONVERSION ALERT */innerText;

13. crmForm.SetLabel converts to:
       Xrm.Page.getControl (\"estimatedvalue_base\").setLabel();

14. crmForm.GetControl() converts to:
       Xrm.Page.ui.controls.get()

15. Conversion alerts added for any of the following external file extensions:
       .js, .aspx, .css, .asmx

16. When inserting a conversion alert, the previous code block is checked and if a prior conversion alert is found, a new one is not inserted.

17. crmForm.all.name.MaxLength is now converted to:
       Xrm.Page.getAttribute("name").getmaxLength()

18. crmForm.all.new_field.SelectedIndex converts to:
       Xrm.Page.getAttribute("new_field").setValue();

19. crmForm.all.new_field.SelectedOption converts to:
       Xrm.Page.getAttribute("new_field").getSelectedOption()

20. crmForm.all.new_field.Value converts to:
       Xrm.Page.getAttribute("new_field").getSelectedOption()

21. crmForm.GetLabel(crmForm.all.customerid); converts to:
       Xrm.Page.getControl("customerid").getLabel();

22. oNavItem.style.setAttribute("display", "none"); converts to
       oNavItem./* CONVERSION ALERT */style.setVisible(false);

Note: the style reference can probably be safely removed, in the sample above, but this needs to be a manual process.

23. Modified the conversion alert process for ObjectTypeCode.

Conversion Speed Improvements

The conversion time has been reduced again.  Here are the conversion metrics for my main test organization:

Files: 144, Lines of JavaScript: 7,408, Conversion time: 00:00.30

The previous conversion time was 00:00.65.

Wrapping Up

I’ll be releasing updated documentation and videos in the coming days to show the functionality and usage.

I’ll also be conducting a free webinar sometime in the near future to discuss the process of migrating your JavaScript from CRM 4.0 to CRM 2011.

For more information, visit the product page.

if (crmForm.all.new_picklist.DataValue == "2")
{
    // do something 
}

In CRM 2011, the OptionSet value is returned as a true integer so the following code (converted into CRM 2011 object model) will not work:

if (Xrm.Page.getAttribute("new_picklist").getValue() == "2")
{
    // do something 
}

You need to modify it so the equality operator looks like this:

if (Xrm.Page.getAttribute("new_picklist").getValue() == 2)
{
    // do something 
}

This is something very important to remember and something that has cost me me quite a bit of debugging time.