Microsoft Dynamics CRM Team Blog: Part 2: IE 8 Developer Tools and CRM 4 – Client Side Debugging

[Blog bot]

Источник: http://blogs.msdn.com/crm/archive/20...debugging.aspx
==============

Guest blogger and CRM MVP Ross Lotharius provides Part 2 of his observations about the newly released IE 8 . Ross Lotharius is an Associate Partner and Director of Software Development for the CRM Practice of Ascentium.

In my last blog post, I reviewed the Developer Tools available in IE 8 and focused on the Html and CSS pieces of the tools.  In this post, I will take a deeper dive into the debugging aspects of the tools with a focus on debugging script added to forms in CRM 4.

CRM 4 provides the ability to add scripts to forms and fields through the CRM UI.  This provides a very easy way to perform string formatting, client side validation, AJAX calls, etc.  While this is a great feature for CRM solutions; however, this can be cumbersome to debug.  Typically, we add the debugger; statement when we need to debug our script.  Assuming a debugger is installed, this statement will prompt the user to open an instance of the debugger and allow developers to step through line by line of the code.  For developers, this can be a time consuming process because it involves many clicks and possibly publishing time.  IE 8’s Developer Tools has streamlined the debugging script process in CRM 4.  The Developer Tools provide the ability to add break points to your script and begin the debugging without all of the previous extra clicks and without downloading additional tools.

In this post, I will step through a very common scenario where I have added scripting on the Account Number onchange event. This event will check the value entered and make a change. I will walk through this script and will demonstrate how to debug the script using IE 8’s Developer Tools.  I will also show some of the current quirks of IE 8’s debugger and present hot to work around these quirks.

Figure 1 (below) is a screenshot of the Form Editor of the Account entity in CRM 4.  I opened the Account Number field’s properties in the Account form and added scripting for the onchange event of the field:



Figure 1

The script above checks to see if the Account Number is greater than 100.  When the Account Number is not greater than 100, the field is changed to red and the user is prompted with an alert.  In order to use the Debugger, I have intentionally added flawed code to the scripting example.  On line 1, the schema name of account is incorrect.  The correct syntax is crmForm.all.accountnumber.  Figure 2 shows the error message when a user attempts to change the Account Number.



Figure 2

In order to walk through the script, I will add a debugger statement to the onchange event.  Here are the rough steps (assuming you are testing from a preview form):

1. Close the Preview form

2. On the Form customization form, double click the Account Number field to open its properties

3. Choose the Events tab

4. Double click on the onchange event

5. Add the debugger line

6. Click Ok to close the onchange window

7. Click Ok to close the Properties window

8. Click Preview on the Form Customization window

9. Click either Create Form or Update Form

10.Test

The set of tasks described above can be reduced considerably as well as provide a more intuitive experience by using the Developer Tools.  Using the Preview Form, we are now able to step through the code without changing the customizations or adding the debugger statement in my example. 

Note: CRM 4 restricts the ability to right click and hides the tool bar. In order to turn on the Developer Tools, use IE’s shortcut of F12.



Figure 3

After opening the tool, go to the Script tab (Figure 3) and choose the appropriate script file to debug from the dropdown.  To debug the Preview form, choose preview.aspx and search for the script (Figure 4).  When you debug from the Account form, CRM 4 uses FormScript.js.aspx to generate the form script dynamically.

Note: Debugging from the Account form has a quirk that I will touch upon later in this post.



Figure 4

To start debugging, you will need to add a breakpoint and click the “Start Debugging” button at the top.  Then go back to my Preview form, type in the Account Number field and lose focus on the field in order execute the onchange event.



Figure 5

In our example, the debugger has broken on the breakpoint at line 369 (Figure 5).  Stepping through the code, I can see that oAccount is undefined by looking at the Locals window on the right hand pane of the tool.  The tool shows that crmForm.all.account is not returning any values, so I can switch to the Watch window and validate that crmForm.all.accountnumber is correct (Figure 6).



Figure 6

I have written in the wrong schema name but before I continue I want to set oAccount to equal accountnumber instead of account.  To do this, execute the following code in the Console window or the Watch window:

oAccount = crmForm.all.accountnumber

After the code has executed, I can finish stepping through the code to verify that it is now correct and gives the user experience I am expecting.



Figure 7

The code is correct and appears to be working correctly.  I can go back to the Form customizations, update the onchange script, and publish. Figure 8 displays the desired output of the onchange script for our example.



Figure 8



Debugging from an Entity form using FormScript.js.aspx

Debugging FormScript.js.aspx has its quirks in IE 8, but I have a work around.  The Debugger Tools attempt to load the script you have selected when debugging is not turned on.  With dynamic script, this causes an error.  In Figure 9, theFormScript.js.aspx displays a CRM Error Report page.  The page is erroring because it is trying to load the page outside the context of the Account’s edit.aspx page causing a NullReferenceException.



Figure 9

I noticed that when debugging is not enabled, it attempts to load the page anyways. When debugging is on, it displays the cached FormScript.js.aspx and allows you to add a breakpoint and debug (Figure 10).  This issue can cause additional problems because the cache doesn’t always get updated.  For example, if you are modifying the script over and over, the FormScript.js.aspx will sometimes not display the most recent page, but instead display an older version. Clearing the IE cache seems to fix this issue.



Figure 10

Closing

This 2 part blog has only scratched the surface of all the new features of IE 8.  From the developer’s perspective, troubleshooting and debugging with IE 8 is much easier, much more intuitive and does not require additional downloads or installs.  Using the Developer Tools will allow you to focus your time on the code instead of the clicks.  There are still some quirks that need to be worked out, but with all quirks there are workarounds. :)



Cheers,

Ross Lotharius



Источник: http://blogs.msdn.com/crm/archive/20...debugging.aspx