As a Dynamics developer, you may use the Xrm.Page client side API extensively. I sure do. You probably have lots of ideas for how to improve it. I often find there are unsupported things I need to do to accomplish my desired experience... often things I think should be obvious, fit right in without a lot of work from Microsoft, and others will instantly benefit from. (Often things that are undocumented but Microsoft is already doing).
I've added a couple of items to Connect recently. If you find them useful, I encourage you to up vote them so we may have these items in the future.
1. CRM 2016 Client Side API: Add an onRefresh event
I would like to know after all the data on the form has been refreshed. Often I have convoluted rules triggered off of multiple fields that impact whether other fields on my form are visible, enabled, etc. I set my IFRAMEs to a read-only mode if the form is deactivated. I would like to evaluate these rules once, after all onchange events have fired.
Microsoft already implements this event for their own purposes but doesn't expose it to us.
2. CRM 2016 - Client side API: Distinguish between onchange fired by user, asynchronous refresh, and attribute.fireOnChange
Also related to forms refreshing after a save/activate/deactivate. If I change a field in plug-ins and the form refreshes, I may want to treat it differently then if it changes by the user in the UI. I often have fields with side effects which dirty other fields when they are changed. However, if some of our plug-in business logic runs changing that field, I don't want to reprocess that logic (and otherwise dirty the just saved form).
Part of the problem with onchange events firing from the asynchronous refresh is they start firing events before all of the fields have been updated. If 3 fields have to be refreshed, the first event only represents the changes to that first field. You're running on stale data.
Take the two combined: Essentially I would like to have the option to ignore onchange events sourced from an asynchronous refresh and then process the updated state of the record in a new onrefresh event. Or queue up my changes until the onrefresh method is hit and then process them manually.
Post your Connect items you think would benefit the Dynamics community.
