Understanding Duplicate Value_Changed Events In InfoPath Code-Behind

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.

There was nothing inherently wrong with the data retrieval, i.e. I was getting the expected results when I selected successive items from each cascading list. Instead, the root cause of the “double” event firing was due to the fact that the field associated with the final dropdown list was numeric and was not marked as required.

As a result, what was happening was that when the value was changed, the document was modified (by InfoPath) to add or remove the dreaded “nil” attribute on the field, which would trigger the extra firing of Value_Changed. This was not at all obvious, even in the debugger, especially when the value would change from null to non-null.

The first clue I found to what was going on was my Debug.WriteLine() output, where I was writing out the e.NewValue property from the event handler to the Output window. I observed that when the value changed from null to non-null, I would first see the value (POLookup) outputted as null (the attribute being removed) as shown below. Then the second change would fire when the actual value was written (ListItemID 8 selected).

[POLookup_Changed]value is:
[CheckForUpdate]OY = 1 Vendor = 7 PO =
...
[POLookup_Changed]value is: 8
[CheckForUpdate]OY = 1 Vendor = 7 PO = 8

Conversely, when the null item was selected in the dropdown, the Console output showed that the value was changed back to a null, but then the event would fire a second time, and now the numeric field was shown as “true”:

[POLookup_Changed]value is:
[CheckForUpdate]OY = 1 Vendor = 7 PO =
...
[POLookup_Changed]value is: true
[CheckForUpdate]OY = 1 Vendor = 7 PO = true

When I saw the value of true, it suddenly dawned on me what was happening. Apparently, the second change was the  adding of the “nil” attribute by InfoPath. Once I saw this, all I had to do was modify the field to make it required, and the duplicate event firing was suppressed. Fortunately, making the field required had no negative consequences for me.