The Baretta

Came across an issue today with an InfoPath form I am working on. In the form there is a Repeating Table that contains within it both String and Boolean Fields. In order to make the form prettier we have created custom buttons to add a row to the Repeating Table.  These button use an XMLWriter to add a new row. For any new fields (String or Boolean) the writer does the following to create a blank Field: writer.WriteElementString("fieldname", myNamespace, ""); The problem I had was that if you created Boolean fields like the line above, and then tried to Submit the form to SharePoint, you receive a validation error "Some rules were not applied.  InfoPath cannot submit the form" Turns out the Boolean Fields were failing to validate with the empty string value.   This was solved by putting in a value that isn't used in the form for the Boolean Field: writer.WriteElementString("fieldname", myNamespace, " 0 ...

Deploying an InfoPath form Once you have developed your InfoPath form, most likely you will need to deploy/publish it to SharePoint so that the information can be stored and reported on.  There are different methods for deployment, which are also dependent on whether you are publishing a fresh form, or updating an old form. Two methods of Deploying/Publishing Forms When it comes time to deploy your form to SharePoint, there are two different methods with reasons for and against why and when you would use each.  You can publish the form as a Form Library, or as a SharePoint Content Type. Deployment Method 1:  As a Form Library When you publish a form as a Form Library, it will create the library on the SharePoint Site of your choosing, and a copy of the form template can be found here:  http://rootsite/formlibrary/forms/template.xsn Use this method when you only require one library for the forms and the forms do not get consumed by BizTalk for some ...

I feel like there are many sites/blogs/articles etc that list all the wondrous things that InfoPath can do.  They praise how user friendly it is for non-coders, how quick it is to design forms in comparison to Adobe & Visual Studio.  What none of them tell you is that if you want to design a code-less InfoPath form, you are severely restricted in many areas that you wouldn't realise, until of course you need to implement that functionality. "Why would you need to stick to a code-less InfoPath form?" you ask?  Well, in our organisation, the reason is simple.  We plan on creating many automated forms, and we plan on pushing them out to the various departments so that they can administer small changes themselves, only asking for help when they need technical advice. So as a coder who knows what can be achieved with a cheeky bit of C# here and there, I am going to list of issues I've found while trying to create a code-less form: ...