We’ve all been there: you’re putting the finishing touches on a solution when suddenly, something breaks. You barely changed anything, but your previously functional code is now giving you a nondescript error that has half a dozen potential underlying causes.
I recently encountered just such a headache while building an InfoPath form. Once the form was working the way I wanted it to, I added in a few hidden fields purely for formatting purposes. The code compiled without any errors, but when I started testing the form using InfoPath Designer’s Preview feature, it threw an InvalidOperationException.
I went back to the code, commented out the string fields I had added, and everything was back to normal. The fields were present in designer, and the related code wasn’t structured any differently than that of the other fields, so, what was going wrong?
A quick search yielded this postfrom the InfoPath team explaining that there might be a nillable attribute on the node. It looked promising until I read that string fields are not among the affected data types.
Then I ran across this support articlethat referenced the error occurring with string fields. Great, right? Well, it would be, except the solution for that was making sure that my fields contain valid, nonblank values. I was explicitly setting the values of these fields in the properties and I knew they were valid string.
As a last resort, I deleted the fields from the code and InfoPath Designer and re-added them. To my surprise (and relief), my form started working again, but why? The fix was annoyingly simple: the order of the fields in InfoPath Designer needs to match the order in which you add them in the code.
Thus concludes “Obvious Mistakes I’ll Never Make Again: Edition 1.”
I recently encountered just such a headache while building an InfoPath form. Once the form was working the way I wanted it to, I added in a few hidden fields purely for formatting purposes. The code compiled without any errors, but when I started testing the form using InfoPath Designer’s Preview feature, it threw an InvalidOperationException.
I went back to the code, commented out the string fields I had added, and everything was back to normal. The fields were present in designer, and the related code wasn’t structured any differently than that of the other fields, so, what was going wrong?
A quick search yielded this postfrom the InfoPath team explaining that there might be a nillable attribute on the node. It looked promising until I read that string fields are not among the affected data types.
Then I ran across this support articlethat referenced the error occurring with string fields. Great, right? Well, it would be, except the solution for that was making sure that my fields contain valid, nonblank values. I was explicitly setting the values of these fields in the properties and I knew they were valid string.
As a last resort, I deleted the fields from the code and InfoPath Designer and re-added them. To my surprise (and relief), my form started working again, but why? The fix was annoyingly simple: the order of the fields in InfoPath Designer needs to match the order in which you add them in the code.
Thus concludes “Obvious Mistakes I’ll Never Make Again: Edition 1.”
