I don't know about you, but I sometimes ignore the Design Checker in InfoPath - especially when it is throwing an error over some poor expression box (calculated value) that it thinks is bound to a repeating group (what's that about any way? Aren't these things not bound to anything? Isn't that the point?).
Clicking on one of the errors above in my form popped up this dialog:
The text of the error is:
Control binding is not supported
And the message text is:
Binding a non-repeating control to a repeating field or group is not supported in Web browser forms. To fix this problem, remove the control or replace it with a repeating control, such as repeating section or table.
And one of my calculated values was selected. The cacluated value was displaying data from a repeating node in a secondary data source, but the XPath had a filter on it - only one value was going to be returned.
The form could be admin approved, and opened and ran in the browser without error.
But then, I added a print view to the form. Clicking the Print Preview button in IPFS would not switch to my print view if there were any design checker errors on the view that used the print view.
Gee. I could add a bunch more fields to my main data source to hold the "display" values for all the fields that I needed to be able to show info from my 2DS in this view. That seemed like a horrid idea.
So, I saved the form as source files and took a look at the view - searching for ExpressionBox took me to one of the culprits. There was an "xd:binding" attribute that had the complete XPath for the expression - it was easy to see that the xsl:value-of node would be providing the actual value. Other expression box controls did not have this attribute, so I removed it and saved the view. When I opened the manifest.xsf in design mode, my design checker errors went away, and Print Preview started working as anticipated.
As always, before you save your form as source files and start poking around in them, make sure you have a backup copy.