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:
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:
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…
So, yesterday I’m working away on migrating a form we have into a SharePoint list. I build all the columns, and then start customizing the form with InfoPath. All is going well. That is, until I made changes to the list columns. I found out very quickly that you need to pay attention to when you do this in relation to the InfoPath form editing.
If I make the column changes in the list and then open the form up for editing in InfoPath, I get the following message:
Basically, the list has changed, and would you like to have your InfoPath form updated with the new list of fields? For me, the answer is yes.
The mistake I made was once again updating columns in the list, but neglecting to close the InfoPath editing session first. That gives you *this* message when you save the InfoPath form:
Basically, you changed the list columns, but the InfoPath form doesn’t know about those changes. So I’ll just overwrite the column changes and make the list match this InfoPath form, OK?
No, not really!
The two different situations make sense when I think about it, so that’s not really an issue. The problem is that it’s easy to think you’re answering the wrong question if you don’t pay close attention and just quickly choose the option to continue. Fortunately in my case, the changes I lost were to two new fields that I could quickly recreate. It could have been much worse.
Recommendation… Make sure your InfoPath editing session for the list is closed before making column changes. THEN you can open up your form and continue…
This’ll teach me to not try new things on the spur of the moment… 🙂
I was setting up a new site collection, nothing fancy. Normally when I do that, I base it off the Team Site template, just because it gives me a few of the lists that users might want. This time, I decided to go with a Blank template.
I’ll just keep it basic, I thought…
All was fine, custom list created, columns added. Now time to customize the list forms in InfoPath, and… Where’s my Customize Form ribbon bar button for the list?
I hate things that should be so simple to “fix”, but still take me a long time to figure out. Turns out that many of the Site Collection Features I take for granted by basing a site off of the Team Site template aren’t there for a Blank template. After some back-and-forth comparison, I found that I needed to activate the SharePoint Server Enterprise Site Collection features option. Once I did that, I got my Customize Form icon back, and I can carry on.
I’ll note that here so when I forget about it in three months and hit it again (because I don’t learn), I’ll vaguely remember… “Hey, didn’t I solve this once a while back?”
Here’s a shoutout to a great source of free online training that’s quick and concise (and often very practical)… Qdabra’s free Thursday webinars.
Their Thursday webinars (at 8 am Pacific time, so *very* convenient for me) are only about 30 minutes long, so they get to point without much fluff. Even though Qdabra has SharePoint software to sell, they don’t tie every webinar to something you have to buy from them. It’s just very good information that is perfect for those of us who are always looking for some tip that will improve our solutions and sites.
I have an InfoPath 2010 form that is used in a particular site, and it’s designed to be used with InfoPath Filler as the client. I use a URL similar to the following on the site home page to allow the user to launch the form:
Of course, it works for me, as well as 99% of all other users. But for a few people, the following error shows up after clicking the link:
Generally I have the help desk make sure that their OS and browser is set to launch .xsn files as InfoPath, but in this one particular case it didn’t seem to make a difference. The user was still getting the error. What gives?
It turns out that if you’re using a non-Internet Explorer browser like Firefox, you’ll get this error. Since we use IE as our “standard” in-house browser, it’s a matter of having them use IE instead of Firefox or Chrome or whatever.
I realize the right answer would be to “fix” things so that .xsn files would be launched correctly (with InfoPath Filler) regardless of the browser being used. But there doesn’t seem to be a way to add .xsn files to Firefox as a “new” application to use. Given this particular situation, I’m fine with just figuring out the “why” that caused this not to work for the user in the first place.