However, we noticed some other strange errors, for instance bool fields with Yes/No values with No as default, were shown as "False" when the form was in create state. Once the form had been saved this error went away.
Another error we saw was that if you tried to save emails, (not send them), you got an error message. The email got saved anyway, but you got a nasty message.
However, if we switched back to turbo forms, both this email error and the bool-error disapeared. Hence, it seems the legacy form controls are not nearly as well quality tested as the turbo form versions so I would strongly suggest that you do not use them unless you have no other option, and then try to move away from them as soon as possible.
So, trying to stick to my paradigm for troubleshooting; "Find where the error is first, then what the error is" - I wanted to go back to the case entity and find out why the turbo forms didn't work.
Rickard and I, who were troubleshooting this together, enabled the dev-mode in IE (pressing F12, if you don't know it) and opened a case. The odd thing was that the point where it broke was in one of Microsoft's functions. I have been unable to recreate the error now so I cannot show it. And after some nitty gritty debugging in IE, we found that the script seemed to be missing "productid" and "primarycontactid" or in laymans terms, Product and Contact.So, I added them to the case form, and magic! It worked.
But the story doesn't end there. As I thought that this might be a good blog article and I wanted to recreate the error to have as a screendump, I removed the fields again... and mark my surprise when the form still worked... twilightzone.
Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se
