Alec Pojidaev's InfoPath Blog
Stuff published for no reason (cool codeless infopath solutions mostly)


There is no out of the box way how to create custom view which supports merge functionality. But such minor obstacles shouldn’t stop you from creating as many merge views in your library as you want.

1) Click “Create new view” link in your form library
2) Navigate to the “Start from an existing view” section (and we going to do so not to just one more time to ensure that merge view are not presented among proposed choices)
3) Right click on any of the choices and copy shortcut to clipboard
4) Open NotePad (or any other editor) and paste
5) Open existing merge view and click “Modify this view” link
6) Copy part of the hyperlink in your browser which is in between ‘View=%7B’ and ‘%7D&Source’
7) In NotePad replace part from ‘View=’ to the end with information from your clipboard
8) Copy resulting link into addres bar of the new browser window and press “go to” button.
9) Enjoy your new and shiny merge supporting view :)


Other parts: 1, 3.
Bookmark that post

Tested for SP2007 web forms, SP2010 list and library forms (note: the form has to be redesigned significiantly for list form because of different data fields structure).

Updated: 5 more forms added at the bottom: “work days calculation (excluding weekends and holidays)”, “work days calculation in the list form”, “day of the week calculation”, “Days since form was created” and “Hours Calculations”.

Special thanks: Karl D. Swartzendruber, Karin Edmondson

So what about so called “codeless programming” in InfoPath? As we all probably know, InfoPath can performed only 16 calulations without user interaction. But what if your business rules require you to iterate through 17 repeating elements? You will get a message box from InfoPath with phrase “The rules or code may be causing an infinite loop”. Yes, in InfoPath 16 is a very big number and 17 is considered infinite. To you and I this might seem stupid and arbitrarily restrictive, but Microsoft’s wisdom is greater than ours. Perhaps they know that 17th iteration would give us developers too much power. It would break the fine balance of Microsoft applications, make other development tools obsolete, and become unbearable for non InfoPath developers. But let’s drop the light irony and just accept that InfoPath already has more codeless programming power than mere mortals should ever need.

Today’s challenge is to find the difference in days between 2 datepicker controls disregarding the absence of datediff() function in InfoPath. We are going to show that the 16 iterations limit just can’t stop the true codeless programmer.

Disclaimer: During developing cycle author has been having in mind “finite automates” principles as well as primitive binary search.

Anyway, lets get to the business. Date Difference Calculation. Form to download.

Our recipy is the following: We will need 3 fields. 2 of them are date type fields with datepicker controls (startDate, endDate) and one (dayDifference) is a text type field represented by a simple textbox. All rules have exactly 1 action.

startDate rule:

condition expession: ../my:endDate != “”
field: dayDifference
string value: 0;4096

endDate rule:

condition expession: ../my:startDate != “”
field: dayDifference
string value: 0;4096

dayDifference rules:


condition expession:
xdDate:AddDays(../my:startDate, substring-before(., “;”)) != ../my:endDate and contains(., “;”)

field: dayDifference
xPath expression: concat(substring-before(., “;”) + substring-after(., “;”) * ((translate(xdDate:AddDays(../my:startDate, substring-before(., “;”)), “-“, “”) < translate(../my:endDate, “-“, “”)) * 2 – 1), “;”, substring-after(., “;”) div 2)

finalize rule:

condition expession: contains(., “;”)
field: dayDifference
xPath expression: substring-before(., “;”)


Your form is ready!

What else can be done by applying same principles:

Here is form
that shows amount of days since it was created
Form that shows current day of the week and day of the week from Date Picker control.
Same but with Hours: Hours calculation
The tricky one: Work days calculation (business days)
Work days implemented in the list form.
This form was kindly provided by blog reader Karin Edmondson. The form won’t open in preview mode because of the obvious reason – the connections are pointed to Karin’s server. So your only option is to examine his formulas and try to reproduce them in your own form. Also another nice thing about this form is it takes into account half days.

That’s it. Happy codeless programming!

Posted under tags: Infopath, Date Picker Control


Special thanks: Karl D. Swartzendruber

Other parts: 2, 3.
Bookmark that post

Let me guess what might have brought you to that blog page about codeless programming in InfoPath. Any of you who developed at least one sophisticated InfoPath form sooner or later have been realized that writing forms with real complex behavior is impossible without some sort of coding in C# or VB.NET. So developers have no choice but to deal with mixed developing environment like Visual Studio, managing form security levels, security certificates and so on. But there are people who like to keep things simple. At least I do. And that’s why probably you are reading that page too:)

Anyway, lets get to the business. How to iterate an Infopath Repeating table?

Here is our scenario: we have a repeating group on the form which will be populated with wonderful (but often overlooked) Contact Selector Control with some user information. The control provides us all necessary information about user except his email.

But wait, that is outrageous! The email was the only reason why we decided to use that now not so awesome control! Well… at least we have access to the web service which able to return user email in exchange of account name. There are countless blogs describing how to utilize UserProfileService to get info of a single user in Contact Selector. Here I’ll try to demonstrate how to deal with multiple selection in Contact Selector. So now our task is clear – we have to construct a string acceptable in Email address field iterating through repeating group and submitting query to the web service on each cycle of iteration.

Let’s go.

The first things first – here using-the-contact-selector-control you will find detailed explanation how to utilize Contact Selector Control. The resulting data structure for the control in main data source should look like this

The Control also requires secondary data source

Add text field named HlinkToEmail. That field will hold result of our computations. Resulting Main Data Source:


When your new shiny control starts providing you users from your network that means we are ready for the web service part. Here we’ll use SharePoint GetUserProfileByName web method. You will need SharePoint Services running somewhere on your network. That part is pretty straightforward. Add secondary web service receive connection. Your link in connection settings should look like


The results of that part:

“Programming” part

Place a button on the layout. At Rules and Merge tab create rule named setfCounter. Press “Set Conditon”. In the first area choose “The expression”. Here is string to paste in second area:


The only action will assign initial value to the HlinkToEmail field. Press fx button at new action form. Check “Edit XPath (advanced)” checkbox. To avoid too detailed instructions of choosing functions and form elements just copy paste the following expression:

xdMath:Eval(xdMath:Eval(my:Person, 'concat(my:AccountId, "|")'), "..")

If you prefer more automated design (no button needed) the same expression above may be used as default value of the HlinkToEmail field.


At main data source pane double click at HlinkToEmail field. At Rules and Merge tab create rule named fConterRule. It’s a conditional rule. In the Set Condition dialog in the first area: Choose The expression. Then paste this expression into second area:

contains(., "|")

The resulting set of actions:


The rule will consist of 3 actions. The fist action will be setting AccountName field of data source named GetUserProfileByName to the portion of HlinkToEmail field. Check “Edit XPath (advanced)” checkbox. Paste Xpath expression:

substring-before(., "|")

Next is self-explanatory action. Add action -> Query using data connection -> Choose GetUserProfileByName.

Add the last action to set HlinkToEmail field to the new value by assigning following XPath expression:

concat(substring-after(., "|"), ";", xdXDocument:GetDOM("GetUserProfileByName")/dfs:myFields/dfs:dataFields/s0:GetUserProfileByNameResponse/s0:GetUserProfileByNameResult/s0:PropertyData/s0:Values/s0:ValueData/s0:Value[../../../s0:Name = "WorkEmail"])

We done with actions of that rule. Make sure that check box “Stop processing rules then this rule finishes” is checked.

Add the last rule right after fConterRule. In Set Condition dialog choose The expression. In expression area copy paste:

substring-before(., ";") = "" and contains(.,";")


And finally, set the HlinkToEmail to the following XPath expression:

substring-after(., ";")

That’s it.

P.S. Now you know how to iterate and read repeating structures. But what if you need to write? Well, InfoPath doesn’t provide UI to parameterize repeating structures are assigned to new values. Still here you will find a workaround which overcomes this limitation.

Posted under tags: MOSS Contact Selector Control Infopath Sharepoint