Category Archives: InfoPath 2010

This error has been killing me of late. I have a SharePoint 2010 list with a form that’s customized in InfoPath. Admittedly, the list is *very* large… as in over 74000 items. I know… it should be smaller, but that’s another discussion for another time.

The form has always taken a bit of time to publish, and the time has increased as the list has grown. Recently, I made a small change to the form, and it would no longer publish. I started getting the following error – “The SOAP message cannot be parsed”:

I tried a number of methods to “fix” the problem, based on various online posts and blog entries. Most of them recommended changing IIS timeout setting, but that wasn’t solving it this time for us.

Then I found this blog entry: https://spjohnadams.wordpress.com/2012/11/11/soap-message-could-not-be-parsed/

It was this part that was the revelation:

I had one calculated field in the list, and ironically it was one I really wasn’t using. I deleted that field and then republished the form. Not only did it publish, but it did so in about 10 seconds (as opposed to the minutes it used to take).

I would have never thought that a calculated field would have that effect on publishing a form, but there you go.

This is one of those errors that doesn’t have a lot of history to pull from if you Google/Bing it to find help. I’m putting this one out here to help rectify that in some small way.

We have a site where we built a small custom list and then customized the form in InfoPath. As part of that form, we had a formatting rule that used pattern matching in order to hide a section. This was used to get a form of validation on a People Picker column.

All was going well until we embedded the form in a wiki page using an InfoPath Form web part. Then all hell broke loose. The page (AND the form) started returning this error:

Failed to render “Wiki Content” column because of an error in the “Multiple lines of text” field type control. See details in log. Exception message: Function ‘xdUtil:Match()’ has failed..

The form was easy and fast enough to rebuild when it appeared the first time. But when the form and page broke again later in the day, we knew that something had to be done. Breaking and rebuilding the form every time you want to change it really isn’t very scalable. 🙂

The xdUtil:Match portion of the error seemed to point to some type of issue with pattern matching. We wondered if perhaps the pattern matching rule we had in the form wasn’t playing well in an embedded form scenario. Once we removed that rule from the form and republished it, everything returned to normal and our problem was resolved.

While I still don’t know the details of why that broke the page and for what reason, I’m happy enough to live with “don’t do that ever again” when it comes to this situation… especially since I found a way to get the same formatting rule in place using something other than pattern matching.

I have a customer testing a new custom list that tracks policy and procedure reviews. The form has been altered using the Customize Form button that opens up InfoPath (yes, I love InfoPath!). Everything has been going well, except for a certain enhanced rich text control on the form. The customer reported that they did not have any way to make a hyperlink in that field.

It’s set up in the list to be a multi-line text field that uses rich text (so I can allow for hyperlinks). I have another field that’s set up the same way. On the form, the second field works just fine. You go into the field, highlight a word or phrase, and you get the option to make it a hyperlink in the Ribbon Bar. But that first control… not so much.

I checked the list and they were identical in how they’re set up. I checked a list item and there were hyperlinks in both fields. Looks like it works to me. She replied that she must be doing something wrong, as she wasn’t getting the hyperlink option. I went out there in a new item, and guess what… I wasn’t getting the hyperlink option either.

When I started looking at the properties of the control, I found an option that I guess has always been on by default, and I’ve never really noticed it before:

It was unselected in my problem control, and that’s why I wasn’t getting the hyperlink options. When I selected that option and republished the form, it worked just like the other control did.

Lesson… pay attention to *all* the properties, even the ones you normally overlook.

So I got this request to make a multi-line text field scroll in one of my forms. That sounded easy enough. But there seems to be a problem when you also have a line-character length set. If you set a line character limit, it greys out the ability to set it as a multi-line field.

To get around that, I decided to hack the field validation a bit. Instead of using the character limit count in the list item, I used an expression in the validation rule to check the character length and fire an error if it’s over 320 characters:

That was the magic combination to allow the text to scroll down in the field, while still limiting the number of characters allowed. Instead of just stopping at the 321st character, it fires a validation error if it goes over that length.

Not quite as clean as the character size limit field on the list item, but it works.

This was a strange one learned today under a bit of pressure (and a crazy idea that I thought of on my very own!)

I have a list in test that I’m keeping separate from the production list due to a ton of significant modifications that have changed/rechanged/scope-creeped over the last three months. Requests to change the “form fields” had, up to this point, just been changes to the labels in front of the fields. I didn’t worry about making the minor name tweaks in the actual list fields because I didn’t want to deviate any more than I already have from what’s in production.

That was all well and good… until the customer noticed that the column headers didn’t match the field name changes on the form. Late in the game and testing was supposed to start this afternoon, but fine… I’ll do it. I had them give me a list of the column names that absolutely needed to change, and what the field name should be. All normal stuff…

I made the changes in the list, and then went to Customize Form to pull in the changes and re-publish it. I was a bit surprised I didn’t get the warning message saying there were list changes, but I normally don’t change field names like that. I tweaked a couple of things on the form labels, re-published, and let them know I had done all the changes…

… only to find that all the list field name changes had reverted to the old names.

Suffering from insanity, I did the same thing again, expecting to get different results. And true to insanity, I got the same results. What’s worse, I wasn’t seeing a way I could change the field name on the form to get what I wanted in the list.

I sat back for a second and thought… I know the form has to refresh from the list when I add new fields to the list. How can I force a refresh, and if I can, will it grab the field name changes from the list?

“Test Field 1” to the rescue!

I added a test field to the list along with changing a couple of the field names to see if they would be refreshed in the form. The new field triggered the InfoPath form refresh, and the refresh picked up both the new field and my field name changes. Sighs of relief were heard in the mancave office…

I made the rest of the name changes, tossed another test field in there, got the form updated, and then deleted (and refreshed again) the test fields. Everyone was happy, and the “must have by 1 pm” was made with minutes to spare.

I still don’t know why a field name change wouldn’t trigger the form refresh, but I now know I can force it by putting a new field in the list, which WILL trigger the refresh.

In the Notes world, Joe Litton used to call this type of stuff “TJN” (“That’s Just Notes”). In my SharePoint world, I use the “TJS” variation…

I had a help desk case the other day where a customer was reporting a problem when trying to print an InfoPath client application form. She had created a text box field, but if the text overflowed to another page, it would often be truncated.

This sounded vaguely familiar to another problem I ran into some time back, and my SharePoint Buddy had figured out the solution. The Scrolling option on the field had been set to Show Scroll Bar When Necessary. While this works well when the form is displayed on the page, it doesn’t work when the form is printed. It just truncates the text in the box when a page break occurs.

To resolve this, all I needed to do was to set the Scrolling option to be Expand To Show All Text. Once that was done, the print spanned page breaks with no issues.

My SharePointBuddy (SPB) recently ran into an issue on an InfoPath form she was working on. Someone went in to try and update the form, and they received the following error:

This wasn’t a form we wanted to recreate from scratch, yet most attempts to fix it weren’t giving the results we needed.

SPB finally found the answer located at http://social.msdn.microsoft.com/Forums/sharepoint/en-US/f0555e7c-5ba0-40bc-82b8-89b2899f20a6/cannot-open-info-path-file-from-sharepoint

She had the customer take the following steps:

• Go to C:\users\username\Appdata\local\Microsoft\
• Create a backup of the folder “InfoPath” then delete the contents of the original “InfoPath” folder.
• Next, go to C:\users\username\Appdata\Roaming\Microsoft\
• Create a backup of the “InfoPath” folder and then delete the contents of the original “InfoPath” folder

Voilà! The problem was fixed and everyone was happy.

I’ve been working on a site, and one of the fields in the list is a multi-line text box that collects concatenated values from entries on other fields. The underlying core of the site is that this is a custom list that I’m customizing with InfoPath.

I had been putting the different field concatenations one after the other, separated by semicolons. But ideally, it would be nice to have each set on a separate line.

My SharePointBuddy pointed me in the direction of this post: http://blogs.msdn.com/b/infopath/archive/2005/03/04/385577.aspx

It didn’t seem to work for me, but there was a comment in there that talked about actually copying and pasting a line break character in the concat statement in the rule. By creating a WordPad document that has two lines of content, you can copy the end of the first line and get the invisible line break character. Then when you paste it into the concat statement, you get your line breaks in the field!

Here’s how it looks in the rule:

The line break in the concat statement isn’t a manual line break I put in there. It’s the effect of pasting in the line break character from the WordPad document. I also put some notes to that effect in a hidden section above the field so that future programmers wouldn’t “fix” the layout of that statement.

Before, here’s what my field looked like:

With the linebreak copied in there, we now have this:

MUCH better!

We recently started running into a problem when some individuals would try to launch an InfoPath form (running in the InfoPath client) from a URL. It would work for most other people, but not for them. The error started with “The form template is not currently browser-enabled”…

Uh, yeah… I know that!

We finally found that the problem was with Internet Explorer version 9 (IE9) and the Compatibility View setting. Unless your particular site where the InfoPath form resides is set to use Compatibility View in IE9, IE will attempt to launch the InfoPath form in the browser no matter what you do.

Here’s the fix to correct that problem:

http://social.technet.microsoft.com/Forums/en-US/ieitprocurrentver/thread/30506a8a-b368-4873-ad32-e931341e6e0e

It’s a quick fix, but not an intuitive one based on the error message. Make sure to put this at the top of your “check first” list if your InfoPath forms suddenly think they’re browser-enabled for random people…