Recently, another MVP asked in a private forum how one might connect to the “onclick” event of a CRM field. With the new Xrm.Page namespace object model, it seemed that all references to the actual DOM element of the control were lost (or at least, very well hidden). Well, I did some poking around, and I discovered
Xrm.Page lives only within the scope of web-resources and their execution (wherever and however they are scripted to occur); this means that the old days of firing up the IE Developer Toolbar to hack CRM on-the-fly are gone.- The DOM elements are buried in undocumented members of the control object (as opposed to the attribute object). As a consequence, the following hack is unsupported
, but also much easier to implement than the supported method of using a Web Resource to present your own custom controls that drive, in the background, CRM’s native controls.
var controlname = "ownerid"; // The "Owner" field, as an example function myFunction () { alert("I have been clicked"); } Xrm.Page.getControl(controlName)[“_control”][“_element”].attachEvent(‘onclick’, myFunction);
Works perfect, txs!
ReplyDeletePhilip
Thanks for the workaround, this works great. I called a custom function on "ownerid" attribute, but after regular intermediary dialog window (Assign to any user or team) my custom function. Is there any way to skip the intermediary window ?
ReplyDeleteI would like to note that my first observation was incorrect; the Xrm.Page context is available for on-the-fly hacking... you just have to go through "frames[0]" to get to it. Secondly, I think I was too premature in discounting the form's event model and dependency registration mechanics. While the information above is still useful for identifying the interconnected DOM and JavaScript objects, I would not continue to recommend it as an alternative for event subscription on the form.
ReplyDelete