XmlLocation=http://server/site/subsite/_vti_history/<VersionNumber>/FormLibName/FileName.xml

If you copy and paste the URL, i.e., http://server/site/subsite/_vti_history/VersionNumber/FormLibName/FileName.xml, into a browser, you should be able to either render it as XML (if you have an extension or add-in that does that), or you can download it and open it in your preferred text editor. I’ve tried without success to open the prior version of the form in the browser. I keep getting an error, and other people seem to get errors too.

Lesson #2 had to do with sorting a repeating table. My scenario was that I had a SharePoint list, and I wanted two of its columns, the title and the description, to appear in a repeating table, and then use a checkbox field in InfoPath to do multiple selections. A out-of-the-box multi-select list box control in InfoPath 2010 usually works for this kind of scenario, but since I needed title and description fields displayed, I needed to roll my own. My lesson learned was that the sorting code is case sensitive. I was trying lots of other sorting routines, when my problem was just that the case was not perfect. Here’s my code that I used for sorting (not generalized).

private void PopulateRepeatingGroup(Connections dataConn, string dsNodeXPath, string groupXPath, string selectedOptionCodeValue, string selectedFieldXPath, string formOptionCodeXPath, string secondaryXmlOptionCodeXPath, string formOptionNameXPath, string secondaryXmlOptionNameXPath, string formOptionDescriptionXPath, string secondaryXmlOptionDescriptionXPath)
{
    XPathNavigator xnav = MainDataSource.CreateNavigator();
    DataConnections[dataConn.ToString()].Execute();
    XPathNavigator xnavServiceReferences = DataSources[dataConn.ToString()].CreateNavigator();
    XPathExpression xe = xnavServiceReferences.Compile(dsNodeXPath);
    xe.SetContext(NamespaceManager);
    xe.AddSort("*[local-name()='displayName']", XmlSortOrder.Descending, XmlCaseOrder.None, null, XmlDataType.Text);
    XPathNodeIterator xi = xnavServiceReferences.Select(xe);
    while (xi.MoveNext())
        AddNodeToNodeList(xi.Current, groupXPath, selectedOptionCodeValue, selectedFieldXPath, formOptionCodeXPath, secondaryXmlOptionCodeXPath, formOptionNameXPath, secondaryXmlOptionNameXPath, formOptionDescriptionXPath, secondaryXmlOptionDescriptionXPath);

    //Delete the last row of InfoPath Repeating table programmatically
    xnav.SelectSingleNode(groupXPath + "[" + (xi.Count + 1) + "]", NamespaceManager).DeleteSelf();
}

My last lesson for today was to remember to remove item event receivers, and later add them back, when doing anything that triggers an update of the item, for which you do not want the event receiver to run. My situation had to do with adding permissions in the InfoPath code-behind. When you update an item’s permissions, it will trigger an item update. This code was run infrequently, and was not well-tested, until now. So, I programmatically added, and subsequently removed, the specific ItemUpdated event receiver from the list, thereby disallowing an item update event to be triggered.

foreach (SPListItem item in list.GetItems(query))
    try
    {
        item.File.UndoCheckOut();
    }
    catch (SPFileCheckOutException)
    {
        item.File.CheckIn(string.Empty, SPCheckinType.OverwriteCheckIn);
    }

If you have any event receivers or workflows triggered by a SPEventReceiverType.ItemCheckedIn event, then you should programmatically remove the event receivers before the CheckIn() method is called, and re-enable the SPEventReceiverType.ItemCheckedIn event afterward, such as in a finally block.  Also, when using the SPQuery object’s Query parameter, in this situation <IsNotNull><FieldRef Name='CheckoutUser' /></IsNotNull> works great to return only the list items that are checked out.

foreach (SPListItem item in list.Items)

This code is fine for small lists, but when you have a list with thousands of items, SharePoint’s performance suffers.  In SharePoint 2010, due to resources throttling, it would not even let my code work.  I was running my console app as the system admin–I ensured this by using SPSecurity.RunWithElevatedPriveleges.  My production server was set to allow object model overrides, but I didn’t assign SPQuery.QueryThrottleMode = SPQueryThrottleOption.Override.  If I had, I suspect it would have worked, but this code needed to be fixed anyway.  Another option for expensive queries is to run them during a daily time window set in Central Admin.  SharePoint 2010 is supposed to throw an Expensive Query Exception, but it didn’t throw any exceptions–I know this because my code had try catch blocks everywhere and would have caught and logged them.

So, there was a lot of room for improvement in my foreach loop.  I started by creating an SPQuery and set its RowLimit to 1000.  I also limited the fields it was returning.  Then, to perform the filtering on the items, I created a calculated column on my list and set its formula appropriately. I found that some of the SharePoint calculated column formula documentation was lacking, so I had to visit the analogous Excel formula page to get better documentation.   With my calculated column telling me which items were relevant, I could now easily monitor whether the applicable items were processed, and I could add a CAML query to my SPQuery object, specifying the calculated column.

Setting the CAML query was a bit tricky for my calculated column, which returns Yes/No results.  After a bit of trial and error, it turns out that setting the column as Boolean and with values of 1 or 0 does the trick.

<Value Type='Boolean'>1</Value>

My console app runs as it should now: very quickly.

Additional resources: MSDN and a configuration walkthrough.

There is simple “Cannot be blank” validation, in which you just check a box on the field properties dialog. This will produce a ScreenTip that, wait for it… says “Cannot be blank”. This is fine for the most trivial validation scenarios, because that validation rule will always be triggered. So, simple “Cannot be blank” validation rules are only good on fields that must be valid at all times. Many fields will require conditional validation, which is where the traditional validation (by rules or events) comes into play, which I’m talking about below.

In the InfoPath 2007 designer, you must put something into the ScreenTip field, or you can’t save the validation rule. The trick to bypass this requirement is to put a dummy string, like “$$$$” in the ScreenTip field, and then, outside the InfoPath designer, do a “Replace All” on the manifest.xsf to substitute an empty string for “$$$$”. This ensures the ScreenTip is not rendered (at least in the browser), which is nice if you don’t want it rendered.

In InfoPath 2010, however, the designer will let you save and publish with a blank ScreenTip field. I thought that was great, because it would save me the “Replace All” step; but interestingly, InfoPath 2010 actually deletes some validation rules with blank ScreenTip fields. It does this when saving and publishing.

So, be sure to actually fill in something on the ScreenTip fields. If you don’t have anything substantive to put in the ScreenTip field, you can put a blank space to reduce the ScreenTip down to a small, innocuous box when mousing over the field. But you need to put something, or InfoPath 2010 will delete your validation rule.