Monday, November 17, 2008

On Central Admin's Manage Form Templates page, your uploaded InfoPath Form Template's Status is stuck in "Installing" forever -- here's what to do!

Thanks to Srinivas Varukala for this helpful post regarding this challenging and not widely documented problem that you may run into while publishing InfoPath Forms to SharePoint through the Central Administration interface as opposed to straightforward publishing.

Wednesday, November 12, 2008

Poor Man's Encapsulation in InfoPath Conditional Formatting

Clay Fox (Infopath MVP) answered one of my recent posts on the InfoPath newsgroup in a way that led me to the realization that the encapsulation I had been missing while using the same conditions repeatedly throughout my large InfoPath form is actually available in a sort of poor-man's encapsulation way.

Say you want to disable or hide a lot of your form controls if the form has already been submitted according to a field called "Project Status" which is on the "General" view of your multi-view form. This could affect dozens of fields across multiple views that require essentially the same conditional formatting conditions to be true in order to be disalbed, hidden, or rendered read-only.

You might normally enter the conditions in this manner:

But if you have to work all those dropdowns again and again for every control on your form, you have a few problems, including a lot of time required to step through all that tedious stuff, the possibility you'll commit errors while entering the conditions, or that you'll omit certains parts of the conditions from one or more fields.
What you really want is an easy way to make sure any number of fields have these same conditions. That's what programmers would use encapsulation for, but since InfoPath doesn't really offer encapsulation to people configuring forms, we have to use a poor man's version.

To do this, assume you've set up your conditions as shown in the previous image. Next, you want to change the leftmost dropdownon on each line to "The expression." When you do this, you'll notice that the textbox just to the right gets automatically updated to reflect the XPath expression equivalent to what you had previously selected in dropdown lists.

Copy each row after the first row into the first row's text box, separating each clause by the word " and " so you get one long expression in the first row. Delete the other rows, leaving only the first row, with the long expression showing in the textbox. (Make sure you haven't forgotten to separate each clause by " and " !)

If you haven't already done so, copy the long expression out of the textbox into your clipboard, and/or drop it into a notepad file or something similar, to keep it handy.

Click"OK" to close this dialog box, and return to your form in design mode.

Just to understand what all that did, right-click your form control again, and click "Conditional Formatting." You should see the following, which is equivalent to the conditions you established in the first place:

If this is seeming like a long way to go to get the same result, remember that our goal is to achieve some sort of reuse here that saves us time and reduces errors when we're setting up other, identical conditional formatting rules elsewhere on our large form. Well, now you just need to go to those controls, right click and choose "Conditional Formatting" and just select "The expression" and paste in the long expression, and you're all set.
By the way, since I originally posted this blog entry, I've observed that this method does not always work when dealing with controls embedded within repeating tables, and that there may also be some problems when working with radio buttons, so keep your eyes out for those gotchas when testing your form. Fortunately, the old-fashioned way works as a fallback solution for these flaws in the approach.
In the case of a multi-view form, you may need to use the old-fashioned method for the first control on each view, and then recapture the expression before pasting it elsewhere, because each successive view is further removed in the schema, and additional information may therefore be required when identifying your particular field. The telltale sign of this problem is that InfoPath does not automatically convert your expression to a form that looks just as if the old-fashioned method had been used in the first place.
Try it out and let me know what you think!
Again, I have to thank Clay Fox for mentioning to me that you could do this kind of thing.
Clay Fox regularly contributes to:

What to do when you get "Invalid Canary for view file" in browser-based InfoPath form

If this is your problem, Jussi Palo has the solution (thankfully, it's an EASY one):

Friday, November 7, 2008

InfoPath Limits Conditions to no more than FIVE clauses in a single rule!

I was very disappointed to discover that the InfoPath GUI limits my Conditional Formatting rules to a maximum of five condition clauses per rule.

I have a viable requirement that requires me to consider the values of six (that's right, 6) different fields before hiding a control, and this means I can't make it work through the UI tools.

What to do, what to do?!

It turns out you may be able to achieve the desired effect using a custom XPath expression. Standby while I learn XPath well enough to test this out. ;-)

If anyone has any tips to share on how to achieve this, please add a comment to this post.

Thursday, November 6, 2008

Editing an InfoPath form with significant rule complexity? Get to know the Logic Inspector!

Any serious InfoPath form is all about the Rules, but since the Rules you create are well-hidden in the UI, even in design view, it is very tough to keep track of where you left off between form design sessions, and to see all of the rules that might be affecting a particular control on your form.

Someone at Microsoft was looking out for you and me, though, because there is an extremely handy utility in InfoPath called the "Logic Inspector" that will show you a list of all of your rules, data validations, etc., so you can see what you've got under the hood without poking through every field or having to go looking at the dehydrated source files.

Just go to Tools>Logic Inspector from the main menu to see the complete list of rules in play on your form.

You'll find that Logic Inspector presents four groupings of information:
  • Data Validation
  • Calculated Default Values
  • Rules
  • Programming

Even better, let's say you have a control that is heavily dependent on other form controls for its default value, or whether or not you need to set it's value dynamically.

You can simply right-click on that control or field/group in Design View, and then click "Logic Inspector" to see the following VERY helpful pieces of information about the selected control:

  • Logic that depends on the value in this field or group
  • Logic that is triggered by a change in this field or group
  • Logic that may change this field or group

If you're working on any form with a fair amount of rule complexity, do yourself a big favor and get to know the Logic Inspector!

Monday, November 3, 2008

Helpful blog post for cryptic form publish error message

If you get the following error message while attempting to publish a browser-enabled InfoPath Form to your Forms Services-enabled SharePoint site: "The following web server does not appear to be running Windows Sharepoint Services:

Then check out this blog post for a solution:!237C3DEA7120098B!644.entry