January 2012 - Posts - Hilary Stoupa

InfoPath Dev

Hilary Stoupa

January 2012 - Posts

  • userName() and Sandbox

    You may have gotten the feeling from my latest flurry of cranky and short IPFS related posts that I've been struggling with browser forms a bit lately. You would be correct.

    I had a 2010 form with code that I published as sandboxed to my SharePoint 2010 install. I was using the userName() function in a loading rule (to set a field to the user's name, of course). My form threw an error on open - you can find a similar issue outlined here. Apparently the necessary SPClaimProviderManager was not available for sandboxed code.

    In our environment, the December 2011 cumulative updates fixed the issue.

  • IPFS, Design Checker Errors & Print Preview

    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.

  • XPath Resources

    InfoPath tries to help out with XPath via the UI, but sometimes to be able to accomplish complex conditions, you may need to write your own XPath. A good knowledge of XPath is also useful for qRules commands.

    Here are a few online resources I like for getting comfortable with XPath:


Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.