Archive for the ‘Troubleshooting’ Category

I was helping a colleague troubleshoot an issue today involving problems opening an InfoPath XML document created in the browser when it is downloaded locally to be opened in InfoPath Filler.

The reason why this is necessary is to be able to use the “Save a Snapshot” feature to produce a well-formatted PDF, as the server environment lacks any facility for generating these documents. (more…)

I ran into this exception today when trying to reconstruct a published form with a backup of its code-behind project. The exception and message was as follows:

“A first chance exception of type ‘System.Collections.Generic.KeyNotFoundException’ occurred in mscorlib.dll.The given key was not present in the dictionary.”

The project backup was a little out-of-date compared to the form, and  one of the secondary data connections that the form uses to write data back to a list had been renamed.

As a result, when it hit the line:

DataConnections[“<Name of Data Connection>”].Execute();

it blew up and threw the exception. After a little bit of head-scratching, I noticed that the name of the data connection had changed, so simply renaming it in code took care of the problem.

It appears that there is some problem with having two repeating tables in a section, and trying to write data to them programmatically.

For me, such a structure produced the famous schema validation found non-datatype error that is so popular with the kids today. (more…)

Chalk this one up to user conditioning, i.e. being too accustomed to Infopath-based frustration with things that aren’t possible. In spite of myself, I stumbled upon a handy capability that, had I bothered to read the dialog message completely long ago, I would have known earlier.

I am working on a form that will use several sections containing repeating tables, all of which will have an identical structure and be populated at runtime from a secondary data source using code-behind. The sectioning is based on the specific year to which an entry belongs, for example, Year 0, Year 1, Year 2, etc. (more…)

I have a VSTA event handler on a dropdown list in an InfoPath browser enabled form, and was puzzled by an “unexplained” duplicate firing of the Value_Changed event assigned to that field. I am storing the value of the field in the FormState dictionary and using it elsewhere, so the the unexpected changing of the value as described below was causing perplexing behavior elsewhere in the form.

The field is populated by a secondary data source (SharePoint list), its underlying value is a ListItem ID (Integer), and its display value the Title field from the list. This field was connected to a series of other dropdown lists that implemented cascading dropdown list behavior. (more…)

When I first started working with InfoPath projects extended by VSTA, I read somewhere online about someone’s horror story regarding the migration of such a project from one machine to another.

Subsequently, I was unable to find that blog post again, but as I recall, it involved exporting the contents, manually editing the manifest, etc., so I was expecting an ordeal when it came time for me to do this. (more…)

In this post, I referred to a problem launching the VSTA IDE from InfoPath 2010 when trying to add code-behind.

A helpful error message

A helpful error message

As that post mentions, the error is pretty generic, and has a variety of reported causes and resolutions documented online. Here is yet another that is probably specific to the managed desktop environment deployed by my employer, but may be adaptable to others users. Thanks to our HelpDesk for finally getting to the bottom of this issue. (more…)

InfoPath is handy in that it relieves one from the tedium of writing markup to render content in nicely formatted tables. With this convenience, however, comes the potential for difficult to resolve rendering issues if you get “cute” and start merging and splitting rows within the table.

Merging and splitting cells can lead to the wrong CSS classes being applied to table cells, which may be difficult or impossible to resolve through the UI. The short answer is that, when faced with problems like the one described below, you are better off deleting the offending rows and starting over, instead of exporting the content and trying to repair the XSL. (more…)

Update 8-15-2013: It looks like it is possible to include the sum fields within the section, as long as they appear before the repeating table in the Main Data Source, rather than after, as shown in the first figure below.


The error message in the headline is displayed when InfoPath throws an InvalidOperationException, it seems to be a catch-all message that can occur for a variety of reasons when manipulating data sources. One popular cause when dealing with data sources programmatically is trying to set a value on a numeric field that has the so-called “nil” attribute. The solution to this issue is well-documented elsewhere. (more…)

When working with decimal data in InfoPath forms, especially data coming from SharePoint data sources, you may be surprised to find that your value, for example 38.29, shows up in InfoPath as its floating-point representation. For instance, it might look like 38.2899997478 or something similar.

This behavior can be hidden away by displaying the value in a text field, and then specifying a format to hide the unwanted decimal display. Unfortunately, this approach probably does not work if you need to compare (for equality) this value to another field which also has a decimal value in it. (more…)