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.

http://www.infopathdev.com/forums/p/8034/29193.aspx#29193

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):

http://howtocode.blogspot.com/2008/02/forms-server-invalid-canary-for-view.html

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:
http://sharepointserverurl/"

Then check out this blog post for a solution:
http://sheetal-d.spaces.live.com/blog/cns!237C3DEA7120098B!644.entry

Tuesday, October 21, 2008

How To Blank Out A Field's Value In InfoPath Without Using Managed Code

The other day I posted some guidance on how you can effectively fake a multi-select list in browser-enabled InfoPath forms, and even showed how to show or hide another control based upon a selection in that fake multi-select list.

The next level of problem is a tricky one... Let's say you have several options in a drop-down list box that you've embedded into a repeating table, just like I described in my October 20 post. Now, if the user's selections in the repeating table make any sections with controls appear (unhide) elsewhere on the form, and the user enters data into those newly unhidden controls, but THEN they go back and modify the selections in the repeating table such that the section with controls hides again, now what?

As you probably have already discovered, that data will NOT automatically get cleared out just because the section has hidden again. The guidance generally is that you would need to write managed code to remove that data from the .xml that your form is building behind the scenes.

But, in reality, you can use Rules to achieve the desired effect. It's not pretty, in fact it's quite tedious, but it can be done.

Trial and error will very likely ensue if you read the blog posts I read trying to find answers to how to do this... So here are some quick rules of thumb:

1) If you are trying to blank out a field outside of your repeating table based upon a value selected within your repeating table, you're going to want to set a rule at the point of the repeating table control itself.

However, it is important to note that when you attach a rule to a repeating table, it will only fire when the repeating table's structure changes, such as from the insertion or removal of a row. (In fact, I still get surprising results when deleting a row from the repeating table.)

When changes are made to the answers given within one or more of the controls on a row in that repeating table, nothing will happen, despite the existence of your seemingly valid rule. What you'll need to do to account for this is to create a corresponding rule attached to the control itself. The conditions will be the same and the actions will be the same as the rule you placed on the repeating table. The key distinction is that the dropdown list box control within a column in your repeating table has its own event that triggers its rules to fire separately from the repeating table's event, and you need to cover both of these events to get the best possible results out of your rules.

2) If you are trying to blank out a field not involving a repeating table based upon a change to a non-repeating value in your primary data source, you can just put the rule at the data source layer., but are probably better off putting it at the control for the non-repeating value. That way, there is clarity about what really triggers that rule to fire.

3) Take note. You are likely going to have to repeat very similar conditions and rules in a number of places. So far, I haven't found any way to use encapsulation to limit the amount of configuration of rules required to achieve the goal here, but if I do, I'll be sure to post it.

4) Test thoroughly. Rules can make for tricky form behavior, and you need to carefully consider all of the scenarios that can occur.

Monday, October 20, 2008

Make an InfoPath Multi-Select Control That Works In Forms Services And Apply Conditional Formatting to Another Control Based On A Particular Selection

Okay, that title is a mouthful, I know, but to me the way you do this kind of thing in InfoPath is not intuitive, and therefore worthy of a blog post. It’s actually quite easy to do once you’re informed, so I’ll skip the small talk and get to it.

First of all, the scenario. I was trying to give my users a multi-select list control even though I’m working in Forms Services within SharePoint, and then show some additional form controls based on particular selections made in the multi-select list.

As you know, the standard InfoPath multi-select control is not compatible with Forms Services (no, really, I’m serious – it’s not), and although there are some good posts out there on how to achieve the same basic effect using checkboxes (http://blogs.msdn.com/infopath/archive/2004/04/01/106039.aspx ), that didn’t seem like a wise choice to me, since my option list contains more than 100 entries. Checkboxes would just take up too much screen real estate to be practical.

So, the answer for me in such a scenario is the Repeating Table control.

First, I create my Data Source structure (words to live by, btw) as follows:



Next, I drag the RepeatingTableOptions node over to my Design area and pick the Repeating Table option for control type.

Then, I drag “HideSection_Dependent Field” over to the Design area, and select “Section With Controls” as the control type.

For my purposes, I want a dropdown list box control in the repeating table instead of a textbox which InfoPath dropped in there by default, so I right-click the textbox, and select Change To Dropdown list box.

The dropdown list box control needs some data in it, so I put some values in there by right-clicking the drop-down list box control and clicking “Drop-Down list box properties…” In my real-world scenario with 100+ options, I use a SharePoint list to seed the dropdown, but for this example, we can just choose the “Enter list box entries manually” option. I click “Add” and add a list that includes “Dog,” “Goldfish” and “Hermit Crab.”

Next, I right-click the textbox control labeled “Dependent Field” and Change To Dropdown Listbox control. I right-click again and choose Drop-down List Box Properties. I add some manual entries here too, “Cockapoo”, “Labradoodle” and “Schnoodle.”

By now, you probably know where I’m going with the Dependent field... If the user selects “Dog” for the Repeating Field, I want the Dependent Field to become visible. Otherwise, it should remain hidden.

So, finally, I right-click on the Section containing the Dependent Field, and click “Conditional Formatting.” I create the single rule shown below, which basically says if the user’s selections do not include “Dog” then hide this “Dependent Field” section. You’ll notice right off (it took me a lot of trial and error, sniff sniff) that it’s not the Leaf node, nor the Options node, but in fact the Group we created one step above the Options list that is the one that is tested by the rule.




By the way, if you use Options or Leaf, at a quick glance, you might appear to have success, but you’ll find that it only tests the first row of the table in those scenarios, which misses the whole point. If the user selects “Dog” in the second row of the table, the dependent field needs to be able to recognize it just the same.

So there you have it.

You can preview the working example you just created in InfoPath, but since we’re really trying to work around the lack of multi-select list support in Forms Services, deploying it to a SharePoint site is going to be the real test.

Please drop me a note if you found this post helpful.