Comments on: Dynamics CRM 3.0 Client-side Programming: FireOnChange() http://blogs.infinite-x.net/2006/03/04/dynamics-crm-30-client-side-programming-fireonchange/ Knowledge found and lost while working with Microsoft CRM Tue, 02 Dec 2008 15:50:23 +0000 http://wordpress.org/?v=2.6.1 By: edwardsdna http://blogs.infinite-x.net/2006/03/04/dynamics-crm-30-client-side-programming-fireonchange/#comment-487 edwardsdna Wed, 28 Feb 2007 23:07:52 +0000 http://blogs.infinite-x.net/?p=64#comment-487 Hi, I just used your .FireOnChange(); suggestion and it worked great! Thank you for the solution. Donna Hi,

I just used your .FireOnChange(); suggestion and it worked great! Thank you for the solution.

Donna

]]> By: Robert MacLean http://blogs.infinite-x.net/2006/03/04/dynamics-crm-30-client-side-programming-fireonchange/#comment-18 Robert MacLean Wed, 08 Mar 2006 20:44:15 +0000 http://blogs.infinite-x.net/?p=64#comment-18 Thanks for the information on ForceSubmit. I noticed in the SDK while looking at it that for disabled it states <blockquote>The field is displayed as read only to the user; however it can be updated by a script. This field is submitted to the server when it is modified.</blockquote> The second part about being submitted is definately not correct :( Thanks for the information on ForceSubmit. I noticed in the SDK while looking at it that for disabled it states

The field is displayed as read only to the user; however it can be updated by a script. This field is submitted to the server when it is modified.

The second part about being submitted is definately not correct :(

]]> By: mitch http://blogs.infinite-x.net/2006/03/04/dynamics-crm-30-client-side-programming-fireonchange/#comment-17 mitch Tue, 07 Mar 2006 21:37:49 +0000 http://blogs.infinite-x.net/?p=64#comment-17 Robert, You are correct. Disabled fields do not get written back to the database. Ryan Farley has a great article on Read Only and Disabled fields: http://crmdeveloper.com/blog/archive/2006/03/06/17312.aspx Check that out. In addition, look at the CRM 3.0 SDK for the following command: .ForceSubmit It is supposed to set a flag that will cause it be write back to the database regardless of state. Mitch Robert,

You are correct. Disabled fields do not get written back to the database.

Ryan Farley has a great article on Read Only and Disabled fields:
http://crmdeveloper.com/blog/archive/2006/03/06/17312.aspx

Check that out.

In addition, look at the CRM 3.0 SDK for the following command: .ForceSubmit

It is supposed to set a flag that will cause it be write back to the database regardless of state.

Mitch

]]> By: Robert MacLean http://blogs.infinite-x.net/2006/03/04/dynamics-crm-30-client-side-programming-fireonchange/#comment-16 Robert MacLean Tue, 07 Mar 2006 19:55:01 +0000 http://blogs.infinite-x.net/?p=64#comment-16 <blockquote cite="Mitch Milam">only issue with that idea was the fact that most of these Fields were not meant to be edited. They would be read-only. </blockquote> I had a total, grand total and other fields where the value was worked out based on other fields (very similar to your design). I made the total and grand total read only using the disable option on the form designer. The values would be propergated using javascript and this worked fine. Interesting the values of the field would be stored correctly in the database and so, on the creation of the item but if you tried changing them later on the values would not be updated in the database even though they were changing successfully with the javascript. Appeared to me that disabled fields with values in them and null values in the database get written to the database while disabled fields with values in them with non-null values in the database do not get written.

only issue with that idea was the fact that most of these Fields were not meant to be edited. They would be read-only.

I had a total, grand total and other fields where the value was worked out based on other fields (very similar to your design). I made the total and grand total read only using the disable option on the form designer. The values would be propergated using javascript and this worked fine.

Interesting the values of the field would be stored correctly in the database and so, on the creation of the item but if you tried changing them later on the values would not be updated in the database even though they were changing successfully with the javascript.

Appeared to me that disabled fields with values in them and null values in the database get written to the database while disabled fields with values in them with non-null values in the database do not get written.

]]>