of the
Today’s tip is from Tom Pickles – thank you! And, hey, you can be a guest tipster too – just send your tip to jar@crmtipoftheday.com.
I fixed a curious issue today that I thought I’d share. Users had reported that when using the multi-edit form to update multiple cases, the form would freeze when they save, and never close. The records were updated, but you’d have to force refresh the browser window to continue.
After some digging, I found that this only happened when the script containing all our custom case form functions was loaded on the form. The curious thing was that the error occurred even when no functions were being called on the form, so it was purely the presence of the script that was causing the issue.
So what gives? A script sitting there doing nothing should cause no issues. It wasn’t until I started commenting out large chunks to narrow down the problem, that I hit upon the answer… a custom function named “closeWindow”.
As soon as I changed the name of this function, all started working as normal. I can only imagine that there is an internal function called “closeWindow”, which is called when closing the multi-edit form specifically. Instead of calling that, it was trying to run our one, which doesn’t work in that context.
So I guess the moral of the story is to be careful with those function names! Who knows what could be calling it…
Tîpp Jäår
Well, well, well… It sounds like a good case of spießrutenlaufen here! I truly hope that Tom either didn’t write those functions or that he did learn his lesson. Jason “I can make a kettle talk to CRM” Lattimer forewarned us about the importance of the namespaces in Javascript, like, uhm, 5 years ago but it’s never late to be reminded again!
Photo by Samuel Zeller on Unsplash
I prefer the following notation to create a namespace:
function (foobar, undefined) {
‘use strict’;
// private functions
functions init() {
}
// public API
alfa.main = alfa.main || {};
foobar.main.opportunity = {
init: init
};
}(window.foobar = window.foobar || {}));
// using namespace:
foobar.main.opportunity.init()
Daniel,
how is this better? One of the advantages of a namespace, as far as I can see, is my ability to continue extending it in other modules. I don’t see how would I do it with the function.
Cheers
George
Obviously namespaces are the solution to this problem (and really, the forms JS in Dynamics should handle this to prevent the problem for customizers in the first place – but I get that is a lot harder to do than it was for me to write that sentence.)
This will be yet another example of where the clean syntax of Typescript should make it the default language for Dynamics form customization. Namespacing in JavaScript is messy, to say the least. You have to check if the namespace exists and create it? That isn’t how a namespace works in any other language. Yes, it can be done. No, it isn’t easy to read.
So in TypeScript I get this very easy to read and understand code that transpiles to good quality (although not as nice to read.) You can find the JS (and TS) code here: https://goo.gl/SC8WpB.
namespace GreatXrm {
export function closeWindow() {
//Do whatever…
}
}
GreatXrm.closeWindow();