The Multi-line Text Box and its Malcontents - Part III

In Part I and Part II I posted about the problem caused by the static size of the InfoPath Forms Services multi-line text box. Generally the workaround is to use the rich text control, and in fact this is the workaround suggested by Microsoft for a separate issue - KB931426 - whereby the malformed content of a multi-line text box (actually just any old words that include a space) can cause Forms Services to lose it when the form has been designed to be submitted via email.

You'll know something's up when you get the message "There has been an error while processing the form." returned to the browser, along with "Exception Message: Reference to undeclared entity 'nbsp'" or "System.Xml.XmlException: Reference to undeclared entity 'nbsp'" in the diagnostic log.

So the suggested workaround is to change your schema and use the rich edit control. If you'd really rather not do this, there is actually an alternative method. If the text box doesn't contain spaces - no issue, so the workaround is to strip the text box of spaces, replace it with something that looks like a space (ASCII 160 - the code for the HTML non-breaking space character ' '), submit the form using your email data connection, then reverse out the character replacement.

Easy enough. You can even do all this through rules. This post on the InfoPath Team Blog demonstrates a method for using a secondary data source to reference non printable characters (in this case to insert carriage return / line feed characters). First up, you'll want to add a resource file with the following content (the only attribute that you'll actually be using is the nbsp - the others are just for fun)...

<?xml version="1.0" encoding="UTF-8"?>

<characters cr="&#xD;" lf="&#xA;" crlf="&#xD;&#xA;" nbsp="&#xA0;" />

Next, edit the form's submit options to submit using custom rules and add a rule that has a series of actions that first strips the spaces, e.g. set each multi-line text box field's value with a formula like the following, using the technique from the Team Blog post:

translate(address, " ", @nbsp)

Follow these actions with an action that submits the form.

Lastly, add however many "Set a field's value" actions as required to reverse out the character replacement, e.g. using a formula like:

translate(address, @nbsp, " ")