Microsoft Dynamics CRM Team Blog: Client Extensions and Scripting Samples in the SDK Part 2

[Blog bot]

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

Continuing from my previous blog post Client Extensions and Scripting Samples in the SDK Part 1, I will continue to point out a few of the samples for client extensions and scripting that have been added to the SDK.

In Part 1 I covered the following:

• Add Customer Address data to the Case record form.
• Integrate Live Search into your forms
• CrmService method samples

This time I'll cover these:

• Add default form data values using QueryString arguments
• Create Activity Record Templates
• How to Control Update Access for a Field
• Get GUID values for items selected in grids
• OnSave Event Modes

Add default form data values using QueryString arguments

This was a case where we 'discovered' a feature. Back in the days of Microsoft CRM 1.0 I remember a developer on the team showing how field values could be set just by setting querystring parameter values (HTML window.location.search values) to the URL addressable form. If memory serves, that particular capability was never officially documented or supported. Eventually, I believe a change came along that broke it.

Fast forward several years and as we are working on CRM 4 and I'm asking the PM and the developers about ways to set default values using the Onload event. They asked why I would do that when I can just set the values using querystring parameters. This functionality is what is behind the attribute mapping feature in the application. After clearing this with the testing team, we got approval to go ahead and document this.

For security reasons you can't pass arbitrary querystring arguments to the form without getting an error. The arguments have to follow a specific naming convention based on the name of the field attribute you want to set. Complex field types require up to three separate parameters to set a value. And Activities don't support this method.

This capability is documented in the SDK under the topic of Url Addressable Forms and Views. You will have to scroll down a bit to see the information about Passing parameters to set values to new records.

Create Activity Record Templates

Increasing user adoption is all about making it easy for users to quickly and easily perform common tasks. If you want to streamline data entry to support specific process, one way to do this is to provide users with ways to quickly create new records with much of the default data already set. There are a number of ways to do this that are mentioned in the SDK topic Setting Default values.

But I wanted to dive a little deeper into a more problematic scenario. Often times streamlining data entry means creating specific sub-types of a particular activity, a template for an activity where users just have fill in the critical data.

This sample shows how to create buttons on an Account form that provide three different templates for Task records. Each of the tasks records have different default data based on how the button is configured. In this sample they are based on priority; high, normal and low.

Knowing that activities don't support the ability to set field values using a querystring like other entities, I wanted to show ways to work around for this limitation. Normally a form button configured with the PassParameters attribute can be used to automatically pass values like information about the parent record. But that won't allow inclusion of custom querystring arguments. The workaround was to pass custom querystring arguments and then include code in the onLoad event to process them. Then, use a Window.opener to query the launching form to get the data about the parent record.

I think this pattern can be used for a variety of different solutions where users need to quickly create different templates for the same type of record

How to Control Update Access for a Field

Probably the simplest Microsoft CRM web service message that can be called from form events is the WhoAmI web service message. This sample simply disables a field on a form if anyone other than the owner of the record views it. I'm sure if you use your imagination you can think of plenty of other ways where it is valuable to know who is viewing any given record.

Get GUID values for items selected in grids

The purpose of this walk through sample is simply to demonstrate how you can create a page that can be launched from a button that is aware of items selected in a grid. This is a basic starting point for many types of actions that can be initiated from the client.

OnSave Event Modes

Did you know that you can detect which button a user clicked to save a form? You might want to apply different logic in your code depending on whether a user is qualifying a lead or disqualifying a lead. Or, you might want to detect whether a user is deactivating or reactivating a record. The Event Mode in the OnSave event will let you detect this without querying the values of the form.

Summary

I hope that you found something you didn't know was in the SDK. If you have any questions or comments about the samples - or ideas about new samples you would like to see. I'd love to hear from you.

Jim Daly



Источник: http://blogs.msdn.com/crm/archive/20...dk-part-2.aspx