Over the years, this blog has been about many different things related to software development with Microsoft technologies. Since my current role focuses on Dynamics CRM / XRM, that's what it's primarily about right now.

Enable IE10 spell check in a CRM 2011 form

Enable IE10 spell check in a CRM 2011 form

UPDATE: Yes, I am shamelessly promoting IE10 in this post, but this will work in any browser CRM that supports the spellcheck attribute.

Now that Polaris/UR12 is out, CRM works with browsers like IE10 and others that support the spellcheck attribute of the <input/> and <textarea/> tags. According to Spellchecking in IE10, “Spellchecking is active by default on <textarea> and contenteditable elements, and off by default for text boxes.”

As you might expect, the Multiple Lines of Text fields on the form are rendered using <textarea/> tags. Therefore, the spelling error suggestions will be shown. However, Single Line of Text fields are rendered using <input/> tags. Therefore the spelling won’t be checked. I tested this out with IE10 installed on Windows Server 2008 R2.

Notice the first attempt has no red error indicator underlining the misspelled text and the second one does. Fingers crossed that there will be an option in a future release of Dynamics CRM to control configuring spellcheck for form controls. In the interim, you can apply an OBVIOUSLY UNSUPPORTED, but relatively harmless workaround if you really want your textboxes to be enabled for IE10 spell checking. Here’s how:

-Reference jQuery in the form

-Reference a JavaScript file in the form that contains the following function and call it on form load:

function enableSpellcheck(){

$(“:text”).attr(“spellcheck”,true);

}

After applying this, you will see that the text in your textboxes are being checked for spelling errors:

Why is this unsupported? Because the CRM 2011 SDK clearly states here that “HTML DOM manipulation is not supported” when the CRM product owns the HTML. Yes, it’s supported for your web resources because you own that html. The CRM product owns it’s HTML and can never guarantee your code won’t break if you do some wacky DOM manipulation of it’s HTML.

Because of this, I tend to stay away from sharing unsupported hacks. However, this one seems to follow my unsupported hacks rule of thumb. I always ask myself, “what are the potential side effects?” Most of the time, the potential side effects (say after a service update / update rollup) are too risky. In this case, the risk is low but technically unsupported nonetheless. It’s your call.