ThoughtFactory.CreateThought() A random collection of thoughts from an easily bored developer

Now You See It

Today I was helping out one of my colleagues with a particularly annoying InfoPath problem; he wanted to enable the multi-line option for a text box bound to a web service, but whenever he did the read-only option would automatically trigger. Truly frustrating.

Not being one to believe that things are impossible, I decided to take a crack at it at home, and as soon as the kids were in bed I got stuck into Everyone's Favorite Search Engine (TM). Unfortunately, Google was not my friend on this problem; I found all sorts of information about binding Rich Text Boxes to Web Services and forcing text boxes to re-size when using Forms Server, but nothing related to editable mutli-line text boxes.

I decided that the best idea was to try and replicate the problem, so I fired up my trusty Win2k8 VM, made a quick ASMX web service and hooked it up to an InfoPath form. Sure enough, as soon as I tried to enable the Multi-line option of a text box it became read only. Reassuringly, it worked when using an unbound text box, which at least let me know that displaying editable mutli-line text boxes in InfoPath is possible.

The fact that the problem was only occurring with web service data-sources made me suspect that the schema being returned by the web service may be the key, but upon inspection the schema InfoPath created for my web service connection was using exactly the same types as the schema for my default form data-source. The elements were not read only, and I couldn't see anything else out of the ordinary in the schema. So much for that idea.

Then it clicked. The problem had been staring me in the face the whole time in the guise of a huge red circle with a white "x" through the middle; the form was configured for InfoPath Form Services compatibility, which disables certain options. This MUST have something to do with the problem. I quickly turned off Form Services compatibility then turn on the Multi-line option again, and....

... the field became read only. Doh! But wait! There were two sub-options under Mutli-line: Paragraph breaks and Wrap text. In Form Services compatibility mode I could not edit these options, and selecting Mutli-line highlighted both, which in turn highlighted the read-only option, but with compatibility mode turned off I was now free to edit these values.

Then it hit me. I noticed that, by default, I couldn't select the Paragraph breaks option unless the read-only option was checked. That was it! For some reason, InfoPath can't handle having paragraph breaks in a text box when it's bound to a web service

So instead of clicking on Multi-line I clicked on Wrap text. This checked the Mutli-line option for me, and at the very least let me have a text box that could wrap text onto a new line. I could live with not being able to have paragraph breaks, but unfortunately I could only select this mode in InfoPath Form Services compatibility mode, meaning that I wouldn't get all the fancy error checking to make sure that it would work when viewed over the web. When in compatibility mode, clicking on Multi-line would still check the Paragraph breaks option which would then force the control to be read only. I couldn't win.

Or could I? On a whim I turned off compatibility mode again and set up my control to be Mutli-line/Wrap text as described above, then I turned compatibility mode back on. Success! The options stayed as they were, giving me a mutli-line text box that wasn't read-only. I would just have to make the necessary multi-line related changes to my fields with compatibility mode turned off, and only turne it on for the specific occasions where I would need it.

Not a great solution, sure, but at least it works, and that's certainly better than nothing. I'm honestly still amazed that I couldn't find any info about this on Google, though. I would have thought that using a bound multi-line text box would be a more common use case.