Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Raise your hand if you've formatted a two-option field on a Dynamics CRM entity form as a checkbox. Keep it raised if you've implemented client-side form logic triggered by changes to that field. Now, start waving your hand wildly if you've overridden the onclick event to invoke your logic immediately rather than wait for control focus to change. If, like me, you're starting to attract attention, keep reading (and please, put your arm down).
Adding client-side event handlers to the onclick event of checkbox controls on entity forms is an unsupported customization that has been perpetrated across many versions of Dynamics CRM. The technique serves as a workaround to the native onchange event behavior of the two-option (Boolean) field when rendered as a checkbox control. Native behavior dictates that handler(s) are not fired until after the control loses focus. This behavior can create an odd user experience when onchange logic should be invoked directly after the user action (i.e. conditionally display/enable a related form control). The only alternative to the unsupported workaround is to render the field as a radio button control which may not provide the desired user experience.
Until recently, I identified this unsupported customization in Code Review reports, but lowered the severity based on risk level and the lack of supported alternatives. That is until I discovered a minor change in Update Rollup 12. As of the UR12 release, the two-option (Boolean) field's onchange event now occurs immediately when formatted as a checkbox control. Say what!?! This is a change that I (and many others) have been advocating for years. Like me, you may have initially overlooked it in the SDK release notes (V5.0.15) because it's only referenced as a general documentation update to the onchange event. Either way, I'll take it. One caveat: the behavior isn't supported by Internet Explorer 7 or 8. For these versions, the control reverts to prior behavior based on focus change.
Don't believe me? Read about it here. Celebrate briefly (quietly). Update CRM to UR12 (or later). Upgrade your browser to IE9 (or later). Finally, clean up your script libraries that register handlers with CRM field onclick events. As for me, gone are the days of sugar coating the severity of this violation in future Code Review reports. No excuses, no exceptions!
Microsoft Premier Field Engineer
Business Applications communities