This post is a result of solving real life problem for one of my coworkers. The task was to make a multiple choice from secondary datasource and then present this choice on the summary page as a concatenated string. Not too complex, right? The problem was that the multiple choice control was displaying titles while the stored values had to be IDs. So to display concatenated titles somewhere else you need to build query against your secondary datasource applying choices made at multiple choice control. If it would be SQL the solution is clear – it’s called INNER JOIN. The capital letters here doesn’t mean to indicate how great this INNER JOIN thing is nor to indicate that this INNER JOIN thing is kind of luxury unattainable for poor InfoPath developers. :) No, it’s just a SQL notation. So here is the formula I come up with during my attempt to lower the level of suffering of another fellow codeless programmer:

There are two key elements of these formulas:
1) Using function “contains” to provide evaluation of a given ID belonging to the set of selected IDs
2) You have to start XPath for the multiple selection repeating field from xdXDocument:get-DOM() to reset current relative XPath.

From time to time I’m getting into situations where InfoPath and/or SharePoint limitations don’t allow me to implement what I’ve been tasked to do. Like in that case when my cruel bosses were mercilessly cracking whip on me disregarding my whining about damn limitations preventing me to promote InfoPath field to the SharePoint link type field. As I was told, “Without beautiful icon (link type field can be represented as an icon, neat eh?) my users might fail to distinguish one type of announcement from another”.

That means it’s a hack time!

1. In InfoPath create richtext type field “MyIcon”. The value of the “MyIcon” field should look like:

http://yourlink , Description
Note these spaces from both sides of the comma.

There are not so many differences in versions of XPath between regular forms and web enabled ones. But inability to reference rows in web enabled forms by the index is one of the most annoying. Here are several XPath formulas useful when interacting with repeating tables:

1. The current row index expression:count(preceding-sibling::*[local-name() = "MyRepeatingGroup"])
As you can see that formula successfully substitutes the position() function not available in web forms.

First of all you have to place your repeating group into the non repeating one. So your field structure should be looking like that:

Field structure

Then as you can see the simple rule f=cleaningGroup will delete all rows. Now we are getting to the point why it never been implemented before. As soon as you will try to assign any value to a group InfoPath will yell at you with the message: “You must select a field. Groups do not have values and therefore cannot be assigned to by this action.” Let’s prove that at least “cannot be assigned” part of that statement is false.

It’s time for some rule breaking.

Now we will screw up the group (“f” in our case) by giving it a temporary name. Create a field at the same level as your group formerly named “f”. Name that field … guess what? Right, with the name “f”. Now InfoPath UI won’t be objecting when you’ll try to create button rule f=cleaningGroup. Delete field “f”. Rename your group back to its original name: “f”.The Form to test. Web browser forms OK.

Deleting single row from the repeating field.

Here is form that is doing exactly this. The way it was created (renaiming hack) is similar to the previous form. There are several limitations assosioated with this approach. First is it supports single repeating field not repeating group. Another “feature” you have to consider before you decide to use this form is unchecking checkbox at single row will delete all rows with the same value (might be useful in certain scenarios). Also because of Multiple selection check box this form can be made browser enabled in SP2010 only.

Place control you like (check box or radio button) on the layout. For check box default “Value when cleared” to false and “Value when checked” to true. For radio button limit amount of choices to 1 and set “Value when selected” to true.

P.S. Actually that form looks as potentially a good example to demonstrate field updating concepts like “push” and “pull” and how they are interrelate with each other. In particulary it would be interesting to explain why the sequence of operators like i=2; i=1; which have no sense in any language can be useful thing in Infopath. (Kind of a statement, eh? But that’s fine, hopefully people familiar with volatile variables concept and multithreading are not reading posts about InfoPath :) )

1) Create field called InitialState
2) At open event assign InitialState field to the following Xpath expression:

.. Yes, it’s two dots :)

3) At the submit rule compare InitialState field with the following expression assuming it’s a rule condition at a button:starts-with(., my:InitialState)
Make sure the InitialState field is a very last node in the myFields group fields list.
I also believe some people might have find interesting the way I used conditional expression to parameterize the output message.

I hope this will be the last publication about codeless programming in InfoPath. In the first two parts I demonstrated few examples where we can see implementations of ‘while’ and ‘if’ like operators. The only area remained uncovered is block of code reusable by multiple controls (analog of procedure/function). Hopefully that approach will be able to address quite frequent complains about absence of ability to copy set of actions/rules across similar controls in InfoPath UI. The essential element of that approach is hidden field with shared set of actions/rules. Form to download