Category Archives: Development

My development efforts ( mostly Microsoft .NET )

Notes from the Field: Working with Dynamics CRM Dialogs

Here are a few notes I’ve collected while working with a Dynamics CRM project involving dialog processes:

Required Fields

There is not a feature to allow a dialog field to be required, Dynamics CRM Tip of the Day, Tip #391: Mandatory fields in dialogs discusses a possible work around.

Float Data Field

One of the possible data entry types is a floating point number, which has five decimal places to the right of the period. Unfortunately, there is no way to change the number of decimal places, so we’re stuck with showing the users all five.

Option Set Field

OptionSets have a few things going for them that make them fairly cool to use, but also have some restrictions.

  • An OptionSet can be displayed as a normal drop-down or a series of radio buttons.
  • There seems to be no way to extract the contents of an existing OptionSet field for inclusion in a dialog so you must manually replicate the contents of the existing OptionSet field. This makes for a secondary maintenance point should you need to change or alter the values of an OptionSet.
  • There is no default value for an OptionSet. Instead, just put the default value at the top of the list.
  • The final thing that is rather cool about OptionSets is the ability to define, and later use, a CRM Data Query to extract a list using a FetchXml query.

Two Option Field

There is no Two Option field, so you will need to create your own using a OptionSet, formatted as either a drop-down or two radio buttons.

Lookup Field

Configuring a lookup field can be a little bit different than you expect. Read Leon Tribe’s article: Dialog Lookup Values For Common Entities for more information and some pointers.

Field Tips

Each field has a Tip property associated with it which will allow you to display additional information or instructions to the user. I can see this coming in handy.

Page Names

Even though we have the ability to break our dialog into pages, and give each page a name, that name doesn’t seem to display anywhere. But it would be nice if it did.



I have honestly avoided dialogs because they seemed so rudimentary and also do not seem to have been shown much love since they were released in Dynamics CRM 2011, but they do have their uses and if the CRM team could carve out a little time to correct some of the shortcomings, then they would prove quite useful.  Until then there are always third-parties like TK Dialogs.

How to capture moble login errors with Azure ADAL

If you are creating a mobile application that uses the Azure Active Directory Access Library (ADAL) component, you will need to learn how and when errors are returned from the component.

Here are a few to get you started:

Error Messages

#1: User presses the cancel button on the first login page

If the user presses the Cancel button on this page:


You will receive the following error message:

User canceled authentication


#2: User presses the cancel button on the permissions page

If the user presses the Cancel button on this page:


You will receive an error message that starts with:

aadsts65004: the resource owner or authorization server denied the request.


#3: User supplies incorrect URL

If you are creating an application that accesses Dynamics CRM Online, you must pass in the URL for the organization you wish to connect to. If the URL supplied to the ADAL service is incorrect, you will receive the following error message:

Error: nameresolutionfailure


#4: ADAL component cannot display the login page

The way the ADAL component works is by displaying a webview control in which is loads the web-based login pages to request user credentials using OAuth. If the ADAL component has an issue displaying that webview, you will receive the following error:

authentication_ui_failed: the browser based authentication dialog failed to complete


Handling Errors

Some of these errors need to be reported back to the user an an error and some do not.

#1 and #2 simply mean the user has canceled the operation and you can probably safely ignore the error and cancel the login operation.  But keep in mind that #2 could also generate a real error but I am not exactly sure of the circumstances where that would occur.

#3 is an error that needs to be displayed to the user, but I would change the actual message to something that makes more sense to the user.

In my case, I was asking for the organization name and the Dynamics CRM Data Center (crm, crm2, crm4, etc.) and if the user entered or selected the wrong information, then I wanted to tell them it was incorrect instead of showing the nameresolutionfailure message.

#4 in all likelihood means that your application is not passing the proper window handle to the control (RootViewController in the case of iOS) which is a condition you need to correct or your app will never work with ADAL correctly.

Want to learn more about Developing Dynamics Plugins?

Hi Everyone,

My Dynamics CRM Deep Dive: Plugins book is in development and is available for pre-release purchase.

The book should be available in late October, but if you purchase now, you’ll receive:

  1. A $20 discount on the final e-book.
  2. The electronic resources that will accompany the book (as they are completed).
  3. Advanced copies of chapters for your own education as well as to provide feedback, should you feel so inclined.

Let me know if you have any questions or suggestions.

Thanks, Mitch

Dynamics CRM JavaScript: Ensure the current record is Saved before opening a new record

In yesterday’s post, Tracing the Dynamics CRM Form Data save Operation, I discussed identifying data that would be sent to the database when you saved a Dynamics CRM record.

Part of the issue I was facing was related to the form not completing the save operation before I opened a new form record. Since Dynamics CRM 2013 and 2015 user interface rarely opens a new window, the user was getting a warning that there was unsaved data when the page was being switched between the Account and, in this case, the Opportunity record.

So to prevent this from happening, I had to wait for the save to complete then open the new Opportunity record.

Here is the code where I do that:


var parameters = { customer_id: customerId, customer_name: customerName, customer_type: customerType, name: Xrm.Page.getAttribute("name").getValue() }; var windowOptions = { openInNewWindow: true }; setTimeout(function () { openNewForm(parameters); }, 2000); } function openNewForm(parameters) { var windowOptions = { openInNewWindow: true }; Xrm.Utility.openEntityForm("opportunity", null, parameters, windowOptions); }

The Details

We are using the JavaScript method setTimeout to wait for 2,000 milliseconds (2 seconds for those of us who are not computers).

At the end of the wait period, we will call a function called openNewForm which will use the Dynamics CRM method Xrm.Utility.openEntityForm, which opens a new Opportunity form.

You may need to adjust the wait period up or down, depending on your environment. The idea is to wait long enough for the save to complete, but not long enough to irritate the user.

Tracing the Dynamics CRM Form Data save Operation

I ran into an interesting issue this week where I was opening up a new Opportunity Entity form from the Account record via a Command Bar button.

The issue was that I was getting a warning that I was about to discard changes to the record I was leaving, and would l like to Continue or Cancel.

I verified all of the JavaScript and found that I was not performing any updates on form load, so there must be something else happening to modify a value on the form so that CRM thinks the record needs to be saved.

But what was being changed?

I thought about it for a bit and realized I could have CRM tell me what was happening, though a little known or used method called

Dynamics CRM, by and large, does not send unaltered data to the database when a Save occurs. By using getDataXml, I can see exactly which field or fields were being modified.


To implement this code, I created a small onSave method:

function onSave() {

Then created an OnSave event on the form properties:


Note: Make sure this event is the final OnSave event to ensure that all of the other OnSave events have completed.

This will display a message box showing what fields have been changed and the new values. Basically the same thing that will be sent to the database.


It turns out that in this particular case, I was programmatically:

  1. Setting a field value
  2. Saving the record
  3. Opening a new related record

The issue was that the Save operation had not completed so the field I had modified was still considered dirty.

This allowed me to correct that issue and now things work as expected.

Up Next

My next article will outline how to work around the saving of the record while navigating to another record issue I ran into above.

Dynamics CRM JavaScript: Working with Tabs and Sections-The right way

Back in March I wrote the following article: Dynamics CRM Developer Tip O’ the Day: Working with Tabs.

Today I was working on some pre-existing customer JavaScript and ran across this:

Xrm.Page.ui.tabs.get(0).sections.get(6).setVisible(false); // Hide section

Don’t ever do that! Bad developer! Bad!

So again, never, ever use the numerical value to reference a Tab or a Section, unless you have no choice. 

We don’t want to use numbers because if you move or add Tabs or Sections, your code will no longer work.

Do this instead:

Xrm.Page.ui.tabs.get("General").sections.get("Details").setVisible(false); // Hide section

As long as your Tabs and Sections are named properly, you should not have an issue.

DFW Mobile .NET meeting this week: Mobile Design Patterns with Xamarin Forms

I am presenting at the DFW Mobile .NET meeting on Wednesday, August 12th.  You can find out more, and register for the meeting here.

In this discussion we will cover both user interface and code–based design patterns many developers may encounter while working with Xamarin Forms to develop cross–platform mobile applications.

I hope to see you there.


Source code recovery tip: Was this written in c# or VB.NET?

Every now and again I run into the unfortunate circumstance where someone has lost the source code to a Dynamics CRM plugin (or something similar).

When you encounter this type of situation your only hope is to decompile the source using the plugin assembly’s DLL file and spend a good deal of time modifying the source code to get close to what the original author wrote.

Today my tool of choice is JustDecompile from the fine folks at Telerik.

Decompilation is not an exact science simply because the code the compiler ended up generating is not exactly like the code the author wrote. Most of the time this is caused by optimizations that the compiler has inserted which replace the original author’s code with code that it thinks is “better” or in some cases, just because.

So when reviewing a decompilation, it is sometimes hard to make a determination if what you see is compiler-generated or user-generated, especially when it is not your code. And I should note that I have seen a lot of code written by people whose main job was not that of a developer, who grabbed some code out of the Dynamics CRM SDK or off of the Internet to solve a problem, without really knowing what they were doing.

So when you look at the decompiled code, you are always asking: did they write it this way, or is this the way it was compiled?

Today I ran into something quite different.

First off, the using statements look very strange:


And some of the comparison operations used methods that I had never seen before:


Which is in the Microsoft.VisualBasic.CompilerServices namespace. 

Very odd.  Why would a developer writing C# use Visual Basic.NET assemblies?

The answer is: They would not.  This code was originally written in VB.NET, not C#.

So I am still going to use the C# decompilation code, but knowing that this was originally written in VB.NET helps me understand a little bit better some of the code that I am seeing.

Just another note to put into your book somewhere.

Upcoming Training: JavaScript Development with Dynamics CRM 2015

Hi Everyone,

I am holding my JavaScript development workshop in conjunction with the CRMUG Academy.

Visit this page to register.

Here are the details:

The goal of this 2 day class is to provide every student with a very thorough introduction to using JavaScript within Dynamics CRM. This is an Internet-based, hands-on workshop with each student provided their own virtual development environment for the duration of the class. Each classroom day will run from 10:45am to 5:00pm Eastern with the virtual environments available for student use until midnight on the second day.

And thanks to our virtual development environments, the majority of our time will be spent actually developing JavaScript solutions for Dynamics CRM. Think labs. Lots and lots of labs. And homework. There will be homework.

We’ll cover the following topics:

  • Creating a development environment ?Setup

    • Source control

    • Working in teams

    • Working with Visual Studio

  • Working with Web Resources

  • Working with Solutions

  • Working with Forms ?JavaScript libraries

    • Form events

    • Form Event Handler Execution Context Reference

  • Working with the Xrm.Page Object Model ?Working with Collections

    • Data operations

    • Tabs and Sections

    • Working with Controls

    • Working with iFrames

    • Working with Navigation Items

  • Ribbon button and JavaScript connection

  • Opening Dynamics CRM Forms and Web Resources via JavaScript

  • Using the XrmSrcToolkit to CRM-related data operations

We will be using about 75 of the methods found in the Xrm.Page object model so you should leave class with a fairly good understanding of where things are and how to access them. If we have time, we will also cover some of the freely available JavaScript components that can be used to aid in your development efforts and to increase your user’s productivity.

Students will also receive a draft copy of my upcoming book on Dynamics CRM JavaScript development along with sample code and utility web resources that should help you kick start your CRM JavaScript development efforts.

Using the XrmSvcToolkit to perform the following operations using JavaScript:

  • Create

  • Retrieve

  • Update

  • Delete

We will also be covering advanced topics such as working with the Dynamics CRM tablet client.

Student Prerequisite Knowledge:

  • Each student must have working knowledge of Dynamics CRM 2011, 2013, or 2015.

  • Knowledge of JavaScript is also required.

Preparation: The detailed instructions for connecting and attending the class will be sent one to two days prior to class. Students have the option of connecting to the class via conference call or VOIP. If using VOIP, a headset with a microphone is strongly recommended. Your instructor will use a hands-on training environment. You will receive a separate email with the setup instructions, and a dual monitor is strongly recommended to facilitate navigation.

Let me know if you have any questions.

Thanks, Mitch

Dynamics CRM Developer Tip O’ the Day: Working with Tabs

I learned an important lesson yesterday, again, on working with tabs with Dynamics CRM forms.

There are several ways to reference tabs when writing JavaScript and using the Xrm.Page model.  You may reference the tab by number, like this:


Note: Tabs are numbered starting with zero for the first tab.

Or by name, like this:


It is always a best practice to use the name of the tab instead of the number because if you ever move the tab around the form, then the number will no longer be valid and any JavaScript you have written which references a particular tab in such a manner will start to cause some very strange user experiences.

By using the name of the tab, you will always be referring to the same tab, no matter where it may be located on the form.

In my particular case, this was a Dynamics CRM 2013 installation that had been upgraded from 4.0.  My JavaScript conversion tool, Transformer!, automatically converts the tab references using the number because of the naming convention applied to the converted forms, which is a GUID.

I had merged the original Information form with the new Entity form and in doing so, I had inadvertently moved the tabs out of place.  The logic in JavaScript involved changing the title of a tab as well as showing and hiding one of two different tabs, based on the value of an Option Set field.

I worked around my issue by renaming my tabs from the GUID value to tabxTab, which was the original CRM 4.0 naming format then modified my JavaScript to use that name instead of the number.

By the way, the same practice also applies to form Sections, which are named and referenced in a similar manner.