Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

September, 2004

  • Microsoft InfoPath 2010

    Auto-Fill from List Box


    This came up on an internal mailing list:

    We have a secondary data source that holds a list of entries; part of the data in the list - a name field - is used to populate the items in a listbox in the view. When the user selects an item in the list, I want the rest of the data from that entry to be used to populate the form's main data source.

    Great scenario! It actually can be done with a combination of rules and filters (though I admit it’s not obvious), so you don’t have to write code for it.


    For this example, I will assume you have a form with:

    • A secondary data source with repeating items (for example, a list of people each with an ID, Name and Age)
    • A dropdown that lists the values in the data source (e.g. displays the name of each person and uses the ID as the value)
    • A set of nodes in your main data source that should be auto-populated when the dropdown changes (e.g. An age textbox that gets the age of the person selected in the dropdown)

    What you’ll need to do is create a rule on the dropdown. The rule will set the value in the textbox by filtering the corresponding value in the secondary data source down to one that matches the dropdown selection.


    Here’s how to do it:

    1. Double click the dropdown to open its Properties Dialog (it can be bound to a node in the main data source or in a secondary one, it doesn’t matter)
    2. Click the Rules button
    3. Click Add to add a rule
    4. Click Add Action
    5. For the Action, select Set a field’s Value
    6. For the Field, select the selectedAge node or whatever node you want to set automatically
    7. For the Value, click the Fx button
    8. In the Formula dialog, click Insert Field or Group
    9. In the Data Source dialog, select the secondary data source and then the age node or whatever node you want copy over
    10. Click the Filter button
    11. In the Filter dialog, set the filter to “secondary-data-source-ID is equal to main-data-source-ID”
    12. OK out of all dialogs, you’re done.

    Note that if your dropdown is inside a repeating section/table, then you will need to manually adjust the value in the formula dialog after step 11 to use the “current()” function so the filter works correctly.


  • Microsoft InfoPath 2010

    Filtering using the current() function


    For some reason, the last week has been full of questions where the answer boils down to “use the current() function”.


    The current() function is an XSLT XPath function which returns the current node. You can read the full W3C Recommendation if you want the nitty-gritty details, but if you wanted to read the specification you’d probably have done that instead of reading this blog.


    You need this function in InfoPath if you’re trying to refer to data across repeating contexts. Some examples:


    ·        Within a repeating table row, you want to build cascading drop-downs

    ·        You want select or filter data from another context by data in the current row

    ·        You want one row in a repeating table to refer to data in the previous row


    These all come down to the same need – within an XPath expression, how do you say “this one”? That’s what current() is for. Whenever an XPath is being evaluated in a repeating context, current() returns the... well... current item.


    Scenario: Within a repeating table row, you want to build cascading drop-downs


    If your schema looked like this:

    • Root
      • Data
        • States
          • State (repeating)
        • Cities
          • City (repeating)
            • @state
      • Selection
        • SelectedState
        • SelectedCity

    And you wanted to have drop-downs bound to State and City which select from the appropriate list, you can build cascading drop-downs using filters. You’d end up with a filter on the list-box items that looked like this:

    /Root/Data/Cities/City[ @state = ../../../Selection/SelectedState ]

    (If you used the interactive condition builder, simply select “The expression” in the first drop-down to show the expression as an XPath.)


    Now let’s change the schema a bit to put the selections into a table – maybe with notes about each selection:

    • Root
      • Data
        • States
          • State (repeating)
        • Cities
          • City (repeating)
            • @state
      • Table
        • Row (repeating)
          • Selection
            • SelectedState
            • SelectedCity
          • Notes

    If you try this in a Repeating Table row (/Root/Table/Row) you’ll find that it doesn’t work as expected:

    /Root/Data/Cities/City[ @state = ../../../Table/Row/Selection/SelectedState ]

    The XPath /Root/Table/Row/Selection/SelectedState - which for practical purposes here is the same as ../../../Table/Row/Selection/SelectedState - actually returns all of the states in all of the rows, and in XPath the predicate a[b = c] returns all a's where any b equals any c. If you parse that explanation carefully, you'll see that you get far more results than you were expecting. In this example, you get a list of all cities from any of the selected states! What you need is a way to say “just the current Selection/SelectedState”.


    The fix then is to modify the XPath to read:

    /Root/Data/Cities/City[ @state = current()/Selection/SelectedState ]

    Scenario: You want select or filter data from another context by data in the current row


    This is actually just a simpler version of the previous case.


    Whereas a normal list of cities might be:


    And a static filtered list would be:

    /Root/Data/Cities/City[ @state = "WA" ]

    A dynamic filtered list would be:

    /Root/Data/Cities/City[ @state = /Root/Selection/SelectedState ]

    To pull the selection from the current table row the final XPath in the predicate needs to be made relative to the current row:

    /Root/Data/Cities/City[ @state = current()/Selection/SelectedState ]

    Scenario: You want one row in a repeating table to refer to data in the previous row


    This one is fun – let’s say you had a quiz (a list of true/false questions) and you wanted to disable controls in the current question until the previous question was answered. You’d use Conditional Formatting to disable the controls.


    If your schema looked something like this:

    • Root
      • Questions
        • Question (repeating)
          • QuestionText
          • AnswerText

    Then within each row you can use this expression to disable the controls:

    current()/preceding-sibling::Question/AnswerText = ""

    To enter this in the condition builder, select “The expression” in the first drop-down.


    (Note: In the example XPaths the namespace prefixes have been left out. Since InfoPath is extremely standards compliant - that is, nitpicky - when it comes to correct namespace usage you’ll need to include these.)


    [Edited 2004-09-13 @ 10:37 AM - one of the XPaths was incorrect]

  • Microsoft InfoPath 2010

    What button was clicked?


    Another question that we get asked a lot:

    I include a Repeating Section control in my form, containing a Button and a Text Box. At runtime, a user inserts 5 items. How do I know which Button was clicked so I can get to the Text Box’s value?

    That’s actually the wrong question to ask. Strictly speaking, InfoPath doesn’t know the difference between the Buttons. They are all identical clones. What’s different about each button is its context within the view, and the view is mapped to the data. (In InfoPath it always comes back to the data.)

    If your schema looks like this:

    • myNodes
      • group1
        • group2 (repeating)
          • field1

    Your view probably looks something this:

    [View Structure]

    Since the Button control is inside the Repeating Section which is bound to group2, we say that the Button’s context is group2.

    So what?

    When the Button event is received, it contains a DocActionEvent object. The event object has a Source property. And this property is the Button’s context node – the specific group2 instance the Button is inside.

    So at this point, you can just use eventObj.Source to refer to data relative to the Button. Probably the easiest thing to do is just do some old school debugging using alerts. Here’s how to make sure you’re getting the context right:

    function CTRL3_5::OnClick(eventObj)


    // Write your code here

    XDocument.UI.Alert( eventObj.Source.xml );


    Here’s what you’d get:

        <my:group2 xmlns:my="">



    And to wrap things up, to get the text inside the Text Box, you need to use eventObj.Source.selectSingleNode():

    function CTRL3_5::OnClick(eventObj)


    // Write your code here

    XDocument.UI.Alert( eventObj.Source.selectSingleNode("my:field1").text );


  • Microsoft InfoPath 2010

    InfoPath Quick Tip: Setting a User Role as the Initiator


    In Microsoft Office InfoPath 2003, you can assign users to distinct categories, called user roles, which are based on job title or other criterion. InfoPath can perform custom actions that vary based on the current user role, such as switching views, conditional formatting, data validation, or filter settings.

    Some InfoPath form designers have found the Set as initiator option for user roles to be somewhat confusing when specifying a role using network accounts. (The Set as initiator option is available when defining a user role by clicking User Roles on the Tools menu, and then clicking Add). Setting a user role as the initiator will cause InfoPath to use that role whenever a new blank form is opened for the first time regardless of how the user is logged on to the network. However, the next time that user opens the same form, InfoPath will use the person's assigned user role instead of the initiator role

    For example, suppose you create a form template with an Employee View and a Manager View and then create a rule to switch views based on whether the current user role is Employee or Manager as demonstrated in Lab 7: User Roles in InfoPath 2003. Because the Employee role is set as the initiator, when a user creates new blank form, InfoPath will always set the user role to Employee even if the current user is not a member of the network group or user accounts specified for the Employee user role. As a result, InfoPath will always switch to the Employee View the first time a user creates a new blank form. Only after the form is saved and re-opened will the rule be applied based on the user role defined for the user's network account.

  • Microsoft InfoPath 2010

    Using CHM files in InfoPath custom task pane


    CHM files are compiled Microsoft® HTML Help files suited for a wide range but mostly used as help files for applications. You can also use them inside the InfoPath task pane because they are URL accessible. There are many formats for the URLs as described in the link below. One of the formats is:


    mk:@MSITStore:<path to CHM file>::<path inside CHM file>


    You can enter an absolute path to the CHM file, for instance on a share or on the file system, but you can also include the CHM file as a resource in your form and access it by just using the filename as the path to the CHM file. The path inside the CHM file depends on the CHM file itself.


    How to find the link from a CHM file


    If you have an existing CHM file, you can easily find the hyperlink to a given page by right-clicking on the page and selecting properties. Note that the URL usually overflows and you can only see two lines, so to get the full URL you must click in the ‘Address (URL)’ field and select all text (Ctrl + A) and then copy-paste the link. For example the link to the first page in the Microsoft Office InfoPath 2003 help file is:






    INFO: HTML Help URL Protocols;en-us;235226


    Microsoft HTML Help 1.4 SDK

  • Microsoft InfoPath 2010

    Problems When Calling into Script Functions in a Task Pane from Managed Code


    We have been receiving questions about problems deploying some InfoPath solutions created with the InfoPath 2003 Toolkit that call into script functions in a task pane from managed code. These solutions work on the developer's machine, but then fail when deployed on user's machines if the MSHTML primary interop assembly (PIA) - microsoft.mshtml.dll - is missing.

    This problem is caused by InfoPath object model members that return types from the MSHTML PIA. The MSHTML PIA is installed by default with Visual Studio .NET 2003, but is not installed by InfoPath 2003 SP1 or with the .NET Framework. As a result, when the solution is deployed on a machine missing the MSHTML PIA, the solution throws an exception.

    There are two ways to resolve this issue: 1) Install and register the MSHTML PIA on the user's machine, or 2) Use late binding in your form code to call such functions.

    Installing the MSHTML PIA on User's Machines

    The MSHTML PIA is a redistributable component installed with Visual Studio .NET 2003 (as defined in the <drive>:\Program Files\Microsoft Visual Studio .NET 2003\redist.txt file), so you can deploy it on all client machines where you want the solution to run. Refer to the End User License Agreement (EULA) for your edition of Visual Studio .NET 2003 for terms and conditions on redistributing components.

    The MSHTML PIA (microsoft.mshtml.dll) needs to be copied to the user's machine, installed in the Global Assembly Cache (GAC) using the Global Assembly Cache tool (gacutil /i microsoft.mshtml.dll), and then registered using the Assembly Registration Tool (regasm microsoft.mshtml.dll).

    Using Late Binding to Call Script Functions From Managed Code

    You may also consider using late-bound calls to objects previously passed by the task pane script to the managed code in your form code. The following is a code fragment that shows how to do this by using the InvokeMember method of the System.Type class in the .NET Framework. Note that the managed code requires FullTrust permissions to work with late-bound calls. For more information on FullTrust permissions and how to deploy form templates that require this permission set, see Understanding Fully Trusted Forms.


       function Initialize()
          var XDoc = window.external.XDocument;

       function MyScriptFunc(s)

    <BODY onload="Initialize();" />
       // Remaining taskpane HTML goes here.


    private XDocument      thisXDocument;
    private Application    thisApplication;
    private object         taskPaneWindow;

    // Note: The MatchPath attribute should match your control's ID.
    [InfoPathEventHandler(MatchPath="CTRL1_5", EventType=InfoPathEventType.OnClick)]
       public void CTRL1_5_OnClick(DocActionEvent e)
          object[] args =  new object[] {"Hello from InfoPath script"};

          // Call into script through CLR late binding using the InvokeMember method.
             "MyScriptFunc",              // late-bound method
             BindingFlags.InvokeMethod |  // binding flags
             BindingFlags.DeclaredOnly |
             BindingFlags.Public |
             null,                        // binder object
             taskPaneWindow,              // target object

       public void SetTaskPaneWindow(object window)
          taskPaneWindow = window;

  • Microsoft InfoPath 2010

    New MSDN Article: Support and Troubleshooting for XML Schemas in InfoPath 2003


    A new article is up on MSDN about working with XML schemas in InfoPath. Although InfoPath 2003 has great support for the W3C XML Schema ("XSD") specification - and even better support with higher performance in SP1 - there are a few constructs that require a little hand-holding. The article also explains in great detail the differences between InfoPath 2003 and InfoPath 2003 SP1 handling of schemas, and some schema constructs that have special meaning to InfoPath.

    Summary: Microsoft Office InfoPath 2003 allows you to create XML form solutions by loading an externally authored XML Schema (XSD) definition file into the InfoPath design environment. Learn how to take advantage of InfoPath support for using externally authored XSD files to create custom form templates, and find out how to troubleshoot common problems.

    Unsupported XSD Constructs
    XSD Constructs with Reduced Functionality
    XSD Constructs with Special Meaning in InfoPath
    Debugging Common XSD Errors
    How to Edit or Author an XSD for InfoPath

    And here's the link:

  • Microsoft InfoPath 2010

    New MSDN Articles on Digitally Signing Data in InfoPath 2003


    Two new articles have been posted to MSDN about digitally signing data in InfoPath 2003 SP1. The first article, Digitally Signing Data in InfoPath 2003, provides details about how to configure InfoPath forms for digitally signing data, including information about new features added in SP1 for signing specific sets of data within a form. This article also provides an overview of the InfoPath object model and code samples for working with digital signatures. The second article, Verify and Add Digital Signatures to Form Data in InfoPath 2003 Using MSXML 5.0 or .NET Framework Managed Code, provides C# code samples that demonstrate how to verify and add digital signatures to data in InfoPath forms from external applications written using MSXML 5.0 or .NET Framework classes. This article also provides a C# example that demonstrates how to override the Digital Signatures Wizard in InfoPath to fully automate the process of signing data.

    Digitally Signing Data in InfoPath 2003

    Summary: Microsoft Office InfoPath 2003 Service Pack (SP) 1 provides new digital signatures features, as well as additions to the InfoPath object model for working with digital signatures programmatically. For example, you can specify sets of data in the form that can be signed separately. For each set of data that can be signed, you can specify whether to allow a single signature or multiple signatures, and the relationship among signatures. With these capabilities, you can customize the digital signatures feature so you can track the status of valuable data.

    Valid Digital Certificates for Signing Data in InfoPath Forms
    Defining Counter-Signatures and Co-Signatures
    Designing InfoPath Forms with Digital Signatures
    Understanding the Digital Signature Status and Verification Process
    The Verify Digital Signature Dialog Box and Nonrepudiation Data
    Using the InfoPath Object Model to Work with Forms Configured for Signing Data
    Code Samples


    Verify and Add Digital Signatures to Form Data in InfoPath 2003 Using MSXML 5.0 or .NET Framework Managed Code

    Interoperability Between InfoPath and MSXML 5.0 Object Model
    Interoperability Between InfoPath and .NET Framework Digital Signatures Classes

    Summary: You can expedite the digital signatures process for your Microsoft Office InfoPath 2003 forms by building external applications that add or verify digital signatures. Find out how to build managed code applications that employ MSXML 5.0 or Microsoft .NET Framework code to verify or add digital signatures to data in InfoPath forms. Learn to set up your InfoPath form templates so they are compatible with MSXML 5.0 and .NET Framework code. Discover how to write custom code in your form templates so that users can add digital signatures without using the Digital Signatures Wizard.



  • Microsoft InfoPath 2010

    Introducing MSDN Web-casts for Microsoft Office InfoPath 2003


    Keep hearing the buzz around Microsoft Office InfoPath 2003 and want to learn more? Excited about the feature enhancements in InfoPath 2003 SP1 and want to really understand how to use them in your applications? Want to learn cool tips and tricks on how to make your applications stand out? Want to learn how the InfoPath product team, product developers and testers use InfoPath and want to hear their recommendations on make use of the cool new features? Want 100% developer content without any marketing hype? If this resonates with you, you will not want to miss the ten part MSDN web-cast series starting in October and lasting through December 2004. In addition to showcasing best practices, each web-cast is designed to highlight the InfoPath 2003 SP1 feature enhancements. Topics covered will include using Visual Studio .NET and managed code to create InfoPath applications, using custom controls in InfoPath applications, managing users and roles in workflow, using script-less calculations, adding security features in your applications through digital signatures and much more. The web-cast series also offers you the opportunity to interact directly with the product team. For hard core technical content, that you cannot find elsewhere, this is a not to be missed series.

    The following is the schedule of presentations starting in October:





    Best Practices for Designing InfoPath Forms

    Scott Roberts

    Tuesday, October 05, 2004

    9:00 AM-10:30 AM

    User Roles in InfoPath 2003

    Josh Bertsch

    Tuesday, October 12, 2004

    9:00 AM-10:30 AM

    Building Advanced Dynamic Solutions in InfoPath 2003

    Jun Jin

    Tuesday, October 19, 2004

    9:00 AM-10:30 AM

    Business Logic in InfoPath 2003

    Yuet (Emily) Ching and Prachi Bora

    Tuesday, October 26, 2004

    11:00 AM-12:30 PM

    Using Managed Code and Visual Studio to Build Solutions

    Willson Raj David

    Tuesday, November 02, 2004

    1:00 PM-2:00 PM

    InfoPath in End-to-End Enterprise Solutions: Integrating InfoPath with Siebel and SAP

    Hagen Green

    Monday, November 08, 2004

    11:00 AM-12:30 PM

    Digital Signatures in InfoPath 2003

    Mihaela Cristina Cris

    Monday, November 15, 2004

    11:00 AM-12:30 PM

    Creating Custom Controls for InfoPath SP-1

    Andrew Ma

    Monday, November 29, 2004

    11:00 AM-12:30 PM

    Programming Workflow into InfoPath Solutions: Using InfoPath with BizTalk Server 2004 and Human Workflow Services

    Rick Severson

    Monday, December 06, 2004

    11:00 AM-12:30 PM

    Database Connectivity in InfoPath Through ADO.NET DataSet Support

    Mikhail Vassiliev

    Tuesday, December 14, 2004

    11:00 AM-12:30 PM

    All times are Pacific Daylight Time (UTC–07:00) until Oct 31, and Pacific Standard Time (UTC–08:00) on and after Oct 31st.

    For details, and to sign up to participate in this series, please click on one of the hyperlinks above.


  • Microsoft InfoPath 2010

    What check box was clicked?


    In a previous blog post we answered the question "What button was clicked?" when a Button control is inside a repeating context like a Repeating Section control. A similar situation has a slightly different answer that's worth calling out for those readers still learning about XPaths and InfoPath's events.

    Here's a different schema:

    • Root
      • People
        • Person
          • Name
          • IsApproved

    And you could build a form like this:

    The previous blog would have let you get from the Button's OnClick event to the data items in the row. But what about the Check Box?

    The Button is an unbound control, so it doesn't have data change events, just OnClick. And in the event object, the Source is the Button's context (the Person node in this case)

    The Check Box is a bound control (bound to the IsApproved node) so it has data change events instead: OnBeforeChange, OnValidate, and OnAfterChange. And the Source will be the node that actually changes.

    Tricky Bit #1: In an XML DOM, the nodes aren't just elements and attributes. The text contents of elements are nodes themselves. So when a user checks the Check Box, the node that changes is not the IsApproved node, but the text node inside! So the Source will be a text node. If you add this to the OnAfterChange for the IsApproved node, you'll see that the Source is just the text node:

    XDocument.UI.Alert( eventObj.Source.xml );

    Tricky Bit #2: If you check the checkbox, you'll actually see two alerts - first with "false" then with "true". To make this clearer, change the code as follows:

        "Source: " + eventObj.Source.xml + "\n" +
        "Operation: " + eventObj.Operation

    You'll see that the first operation was a "Delete" of the "false" value, followed by an "Insert" of the "true" value. This shows just how fine grained the InfoPath data eventing model is.

    So, back to the problem at hand - how do we get at the other items in the row?

    For Tricky Bit #1, you can either add an extra ".." step in your XPath to step up from the text node, or use the Site property of the event object instead. The Site is this is the node where the event is being processed, and since the event handler is on the IsApproved element, the node will be the IsApproved element. (Note that a Button's event object is a different type, and only contains Source not Site, since the event doesn't bubble.)

    For Tricky Bit #2, you can simply ignore every operation type other than "Insert".

    Putting all of that together, you'll end up with event-handling logic like this:

    if( eventObj.Operation == "Insert" )
        XDocument.UI.Alert( eventObj.Site.selectSingleNode( "../my:Name").text );

    One last note - in the form shown, this event will fire and an alert will be shown whenever a new row is inserted into the table. So depending on what you are trying to accomplish, you might also want to filter out default values - such as empty strings - from further processing.

Page 1 of 1 (10 items)