Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    Calling code/script from a Rule


    Rules are a quick way to add dynamic functionality to a form, so a lot of programmers choose to use rules even when they know how to write the code to do the same thing. However, sometimes after writing a complex set of rules they may realize that they need to do something rules doesn’t support, and we know they don’t want to rewrite all their rules in code just to add that one little bit.

    Alas, there’s no rules action type for “Call code”, but there is a roundabout way to call your code anyway.

    Let’s say you have the following function in your form template:

    Function Test(param)
      XDocument.UI.Alert("Param: " & param)
      Test = true
    End Function
    function Test(param) {
      XDocument.UI.Alert("Param: " + param);
      return true;
    Public Function Test(ByVal param As String) As Boolean
      thisXDocument.UI.Alert("Param: " & param)
      Test = True
    End Function
    public boolean Test(string param) {
      thisXDocument.UI.Alert("Param: " + param);
      return true;


    You can call that function from the condition of a rule by using the xdExtension namespace.

    For example, here’s how to call the function from a rule when the form is opened:

    1. Click Form Options on the Tools menu.
    2. On the Open and Save tab, click Rules.
    3. Click Add, name the rule, and then click Set Condition.
    4. Select The expression in the first drop-down list, and then enter: xdExtension:Test(“foo”)
    5. If you want the function to be conditional, then put the condition before the function call with an AND clause. For example, to get if foo>bar, then Test(“foo”), use foo>bar and xdExtension:Test(“foo”). (This is possible because conditions are evaluated using short-circuit boolean evaluation. In other words, they are evaluated one clause at a time, and if the first clause determines the result, then the rest of the conditions are “short circuited” and don’t get executed.)
    6. The Rule dialog box requires at least one action, but if you don’t have any actions to run in that rule, you can click OK if you select the Stop processing rules when this rule finishes checkbox. To avoid actually stop processing rules, make your condition always return false. For example: xdExtension:Test(“foo”) and false (“false” here is actually looking for the node named “false” which doesn’t exist, so returns the empty set, which is translated to false(). You could just as easily use “foobar” or anything else.)

    Finally, extract your form files and add the following attribute to the manifest.xsf file’s xDocumentClass element:


  • Microsoft InfoPath 2010

    Wizards (and we're not talking Harry Potter)

    I just got back from some customer visits in Washington DC (governments tend to have a lot of forms…) and a common design pattern came up a few times: creating wizard-like forms. Since InfoPath provides all the built in tools to do this, without any fancy XPaths or code, I thought it would be fun to blog about here.
    Basic wizard
    Let's say you have a form that would be easier to fill out if folks could focus on one section at a time in a specific order. You can provide that experience by putting each section in its own view, and adding Back/Next buttons to navigate between them.
    1. Open you form in design mode
    2. Open the Views task pane
    3. Click Add New View for each section in your form
    4. Copy and paste each section to its own view
    5. Open the Controls task pane
    6. Insert two Buttons
    7. Double click each button to open Button Properties
    8. Change the label for each button to "<< Back" or "Next >>"
    9. Click Rules to open the Rules dialog
    10. Click Add to add a rules
    11. Click Add Action to add an action
    12. For the Action, select Switch Views
    13. Select the view to switch to
    14. Copy and paste your button pairs to each view and update the rules to switch to different views.
    You can also provide this experience by adding Conditional Formatting to each section and hiding all sections that don't currently apply, but that can be cumbersome to design since the view can get so big, and I find it harder to manage the flow.
    Conditional Wizard
    InfoPath forms are dynamic, and wizard forms are no different. A common pattern is changing what data you collect based on what they selected earlier on. For example, it's tax time, so if I'm filling out a 1040 and select the option button to file as a single, I can skip the step that would ask me about dependents. You can get this in your form by adding a condition to the rule on your "Next" button, and adding a different rule for each view they could jump to.
    Some wizard pointers
    • Keep it simple. Try to minimize the number of controls on each page of the wizard. In fact, if you can ask for only one piece of information on a given page, your users will thank you. That said, if there is related data, keeping all of it on one page can be easier than having to skip back and forth.
    • Make it pretty. One of the benefits of a wizard is that you're not trying to cram all that data onto one page, so you have room to throw a graphic on the left in addition to a nice header. You can also wrap everything in a table to make sure the Next/Back buttons don't jump around. Eye candy for all!
    • Share where you are. If the wizard isn't conditional, leave the views on the View menu so people can quickly jump around if they want, and see how far they have to go. If the wizard is conditional so you don't want people jumping to the wrong pages, you can hide the views from the View menu using View Properties, but replace it with a chart at the top of each page to let them know how far they have to go. A simple text saying "25% complete" can go a long way.
    • Know when you're done. Presumably the last page of the wizard will submit the data. It's a nice touch to provide a summary of the data they've entered so far, and change the label on the "Next" button to "Finish" or even just "Submit".
    If you have any more tips on creating wizard forms, our team and the rest of the InfoPath community would love to hear them, so feel free to comment!
  • Microsoft InfoPath 2010

    Date Calculations in InfoPath


    The SP1 update of InfoPath 2003 added calculation support – the value of a node can be set to the result of an XPath expression. This makes it possible to avoid writing code (script or managed) in many InfoPath forms. Date calculations, however, still require knuckling down and writing old fashioned procedural code.


    InfoPath stores dates according to the W3C XML Schema standard, which in turn uses a variant of ISO 8601 dates. The XPath expression language, however, has no special support for date types – just strings, numbers, Booleans, node-sets and fragments. This means that while you can manipulate dates as strings – you can’t do calculations with them.


    Before we dive into some sample code, though, a few notes:


    You can do date comparisons with XPath! The date format is “yyyy-mm-dd” – always 4-2-2 – which means you can do lexical (“string”) comparisons on two dates and determine ordering and equality.


    As a guiding rule, you should be as paranoid with date calculations as you are with financial calculations. Identify and test your edge cases thoroughly, and make sure your code matches cultural interpretations, not code convenience. For example, if you compare two dates the context and desired result matters. The relationship between a duration in days and an age in years is not simply 1/365 (or 1/365.25, or … ) – the convention for age in most cultures is “has the person had a birthday yet?” so you’d better make sure the code matches. Who wants to miss their birthday?


    A good rule of software development is that if you have to think too much about a problem you’re writing too much code, and the more code you write the more likely you are to have bugs. So the moral of this story is: make someone else do all the work.


    The general pattern for dealing with date calculations in InfoPath is to use an existing library. The two handy libraries for this are the Windows Scripting engine and the .NET Framework. Since we have a lot of script examples on this blog let’s use .NET this time.


    The .NET Framework has a DateTime struct type and if you look in MSDN you’ll find it has plenty of methods and operator overloads for doing calculations such as adding days and computing TimeSpans. Looks good – I bet the .NET people know what they’re doing.


    So basically we just want to convert an XML date into a DateTime, do some stuff with it, then convert back.


    Here are the functions you need:


           private static DateTime Iso8601ToDate( string iso8601Date )


                  if( iso8601Date == null )

                         throw new ArgumentNullException( "iso8601Date" );


                  return DateTime.ParseExact( iso8601Date, "yyyy-MM-dd", null );



           private static string DateToIso8601( DateTime dateTime )


                  return dateTime.ToString( "yyyy-MM-dd" );



    Wow – after that preamble I bet that was a bit of a let down!


    Now let’s use it. I built a simple calculation form that looks like this:


    Date Calculation Form Screenshot


    The button handlers look like this:


           [InfoPathEventHandler(MatchPath="date1_add1", EventType=InfoPathEventType.OnClick)]

           public void date1_add1_OnClick(DocActionEvent e)


                  IXMLDOMNode dateNode = thisXDocument.DOM.selectSingleNode( "/my:myFields/my:Date1" );




                         DateTime dt = Iso8601ToDate( dateNode.text );

                         dt = dt.AddDays( 1 );

                         dateNode.text = DateToIso8601( dt );


                  catch( FormatException ) {}



    Then I added OnAfterChange handlers for the date fields which call a sync method:


           [InfoPathEventHandler(MatchPath="/my:myFields/my:Date2", EventType=InfoPathEventType.OnAfterChange)]

           public void Date2_OnAfterChange(DataDOMEvent e)


                  if (e.IsUndoRedo)






           private void SyncDifference()


                  IXMLDOMNode date1Node = thisXDocument.DOM.selectSingleNode( "/my:myFields/my:Date1" );

                  IXMLDOMNode date2Node = thisXDocument.DOM.selectSingleNode( "/my:myFields/my:Date2" );

                  IXMLDOMNode diffNode  = thisXDocument.DOM.selectSingleNode( "/my:myFields/my:Difference" );

                  IXMLDOMNode ageNode   = thisXDocument.DOM.selectSingleNode( "/my:myFields/my:Age" );


                  if( date1Node != null && date2Node != null && diffNode != null )




                               DateTime dt1 = Iso8601ToDate( date1Node.text );

                               DateTime dt2 = Iso8601ToDate( date2Node.text );


                               TimeSpan ts = dt2 - dt1;

                               diffNode.text = ts.Days.ToString();


                         catch( FormatException ) {}




    You might notice that this is computing the difference in days. The TimeSpan structure represents an interval of time, and days are the maximum granularity that a pure duration can have – month and year durations require a fixed point in time to calculate from;  even weeks can be ambiguous – is that whole weeks or calendar-weeks-spanned? And whose calendar in the first place?


    So how do you go from two DateTime structures to an age? The old fashioned way – “have I had a birthday yet this year?”


           int ageInYears = dt2.Year - dt1.Year;

           if( ( dt2.Month < dt1.Month ) ||

               ( dt2.Month == dt1.Month && dt2.Day < dt1.Day ) )




           ageNode.text = ageInYears.ToString();


    Time calculations are even more fun. No-one mention leap seconds and we’ll get by just fine.


    (Update 1/25/05 @ 11:30 AM PST - having a problem uploading the screenshot to our images site. We'll fix that ASAP.)

    (Update 1/25/05 @ 11:50 AM PST - Fixed!)

  • Microsoft InfoPath 2010

    Got suggestions?

    One of the reasons we started this team blog was to get your comments (spurred by our tips and tricks), so it's exciting to see more folks chime in. Let me just take a moment to fan the flames…
    We're listening
    We're always open to feature requests to help us plan for future versions. And we're also interesting in blog post suggestions, which we'll try to post on quickly. If you have kudos, well of course they're always welcome. So leave a comment to let us know what you're thinking!
    Need support?
    If you need help solving a specific question, you're better off in the newsgroups, where both the product team and InfoPath MVPs are on watch and where there's a large archive of other like-minded questions. For more general issues or something you suspect is a bug, check out the support center. And for common tasks and basic overviews Office Online is your best bet.
    - Ned
  • Microsoft InfoPath 2010

    Introducing the Multi-Select List Box

    InfoPath 2007 introduces a new control, the multi-select list box, for cases when you want to allow users to select one or more items from the list of options. This list of options may be static, or may come from a data source. For example, you may use a multi-select list box to let the user pick the cities affected by the marketing campaign:
    You may also allow users to specify items not on the list by going to Multi-Select List Box Properties, and setting the option to allow users to enter custom values:
    Data source
    Multi-select list box stores data in a repeating field. Every time a user checks an option, a new instance of the repeating field is added; every time an option is unchecked, a field is deleted. This is just like the Bulleted List control.
    Let's analyze the data source at design time, and what goes into the XML when the form is filled out:
    Form Design
    Form Filling
    Data Source Pane
    User Input
    Persisted XML
         <my:city>New York</my:city>
    Default Values
    To specify which (if any) items should be checked in the multi-select list box by default, click Default Values on the Tools menu. Using the marketing campaign example, if you don't want any option to be selected by default, uncheck the only "city" item:
    When you do this, you may see a design-time message that the "Control is bound to a missing field or group". You can safely ignore this message in this case since the point is to not have any checked by default.
    If, instead, you want several options to be checked by default, right-click on the city item, then click "Add another city below", and specify default values for both cities:
    Multi-select list boxes are supported only in InfoPath 2007 client.
    - Alex Weinstein
    Program Manager
  • Microsoft InfoPath 2010

    Advanced server-side authentication for data connections, part 1

    To tier three... and beyond!
    Real-world enterprise applications are seldom restricted to a single server.  Anyone who has created a nontrivial multi-tier application in a Windows environment has had to work around a fundamental limitation in NTLM authentication:  namely, that NTLM authentication tokens cannot be delegated past the second tier.
    Could you bounce off the wall and say that again?
    OK, in simpler terms:
    When you log onto your workstation, you present windows with primary evidence of your identity in the form of a username and a secret – usually a password, but sometimes a certificate or a biometric identifier such as a fingerprint.
    When you connect to a web application in a browser, your workstation contacts the web server and tells the server who you are.  The server trusts the workstation because it knows that the workstation has primary evidence of your identity, but the server has only second-hand evidence.
    When the web server connects to the data server, it passes your authentication token, but the data server won't accept it because the chain of trust is too long.  The data server has only third-hand evidence of your identity.  Bzzzzzzzzzt – thank you for playing!
    With InfoPath 2003, you never had to worry about these issues when designing your form.  You ran InfoPath on tier 1, and the database, Web service, or SharePoint site on tier 2 trusted your computer's first-hand evidence.  Now that you are designing forms that run in a web browser, you'll need to think about tier 3.
    There are a number of ways of dealing with tier 3 and beyond in forms services.  I'll start by briefly describing three simple techniques for noncritical applications, then I'll move on to enterprise-quality solutions, culminating in two technologies that are specific to Microsoft Office SharePoint Server.
    Keep in mind that for form templates that are not admin-approved and fully trusted, the connection settings need to be stored in a Universal Data Connection (UDC) file in a Data Connection Library in order to make a connection to another domain.
    Anonymous connections
    For trivial data connections, such as looking up a list of states to populate a drop-down list, you can simply allow anonymous users to access your data.  Removing the need to authorize the user means that it's no longer a problem that your identity can't be verified on tier 3.
    HTTP Basic Authentication
    In Basic authentication (or digest, which is a slightly more secure version of the same protocol), your browser prompts you to enter your username and a password, which are then passed in cleartext (or in digest form) to the web server.  The web server now has primary evidence of your identity, so the data server can trust it to tell it who you are.  You can set up IIS on your SharePoint server to use Basic authentication instead of Windows Integrated authentication.  While this is a quick way to do an end run around the tier 3 problem, it presents an awkward user experience on the intranet.   This is better suited to the extranet, where getting prompted for additional credentials is a more familiar experience. Don't forget to set up SSL so that your users' credentials are encrypted on the wire.  Otherwise, anybody monitoring your server traffic can read the passwords as they pass by.
    Embedded SQL credentials
    It's common practice in web applications to connect to a database using a SQL username and password embedded in the connection string.  Since this requires putting a password in cleartext in a configuration file, it is not considered a secure method of authentication.  By default, user form templates on the server are not allowed to use embedded SQL credentials.
    Unlike NTLM authentication, a Kerberos authentication token, called a "ticket", can be independently verified at any point in an n-tier system and thus can be delegated indefinitely within the window of time that the ticket is valid.  For enterprises where Windows XP or better is the standard desktop and Windows Server 2003 is the standard server, Kerberos can replace NTLM as the standard authentication method in Active Directory.  This is the preferred method of overcoming the 2-tier restriction on token delegation when available.
    Constrained Delegation
    In constrained delegation, two services on two servers can be configured to allow a specific set of user accounts to be delegated from one service to the other without requiring independent verification of a password.  While this is considered a secure option, it is notoriously difficult to set up and maintain.
    Office Single Sign-on
    Office Single Sign-on (SSO) is a service on Microsoft Office SharePoint Server which was created to help applications on the server overcome authentication delegation issues.  At its heart, SSO is simply a database which stores encrypted username and password pairs.  An application running on the server can obtain a username and password associated with a known SSO application definition and can then use those credentials to log on to Windows and make a trusted connection to a data source. A form running on the server can use SSO to connect to external data by specifying an SSO application ID in the UDC file containing the connection settings.
    Web service proxy
    InfoPath Forms Services includes functionality to forward Web service requests from a form.  The web service request is made using the identity associated with the SharePoint web application.  In order to allow the web service to authorize access to the external data, the user's Windows username is passed in the SOAP header using a WS-
    Security UsernameToken
    In my next two installments, I'll describe in more detail how to use Office Single Sign-on and the Web service proxy to connect to enterprise data from your browser-enabled forms.
    In my next post we'll cover Single Sign On and write some code.
    - Nick
    Program Manager
  • Microsoft InfoPath 2010

    Open your rolodex from InfoPath using the Contact Selector

    Speaking of Outlook integration, Microsoft Office 2007 includes a new control that enables you to choose one or more e-mail address from the address book.
    You can add this control to InfoPath’s list of custom controls by using the Add or Remove Custom Controls wizard like you would for any other ActiveX control.  When registering the control, you can choose most of the default options. However, you must choose "Field or Group (any data type)" in the "Specify Data Type Options" page of the wizard. If you don't choose this binding type, the control will be disabled when you try to fill out the form.
    When you insert this control in a form template, it looks like this:
    When you insert this control in design mode, only a group node is added to the data source. You must manually add additional fields in order for this control to work correctly. To determine the final data structure should be, open the properties dialog for the control and click on the "Items" tab. This tab lists the schema structure that is required.
    As I mentioned, you must manually add these fields to the data source. This can be quite painful if you want to use the control in a lot of form templates. However, here’s a little trick.  You can create a Template Part that contains only the data structure and no controls in the view. Now, when you need to use the Contact Selector, first insert the Template Part to create the data structure.  (This will insert an empty Section control into the view which you can then remove.)  Then, go to the data source, right-click on the group node that was inserted, and select Contact Selector from the More menu.
    Template Parts don't support ActiveX controls so you can't insert the Contact Selector into the template part which would make this even easier. However, using this empty template part that contains only the data structure is still easier than creating the structure from scratch each time.
    Scott Roberts
    Senior Development Lead
  • 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

    Using Relink When Moving a SharePoint Form Library to a New Site


    When InfoPath form files are saved to a SharePoint Form Library, SharePoint creates hard-coded references to the form template in the team site where the forms are being saved.  If the SharePoint Form Library is moved to a new location, the references in the InfoPath form files will continue to point to the old location, even after they've been moved into the new Form Library. In order to fix up the references in the form files to point to the new form template location, you need to perform a Relink operation.

    Important   Before performing the Relink operation, make sure that the Windows SharePoint Services server you are working with has been updated with Windows SharePoint Services Service Pack 1. This service pack release fixes a bug that can cause data corruption when performing a Relink operation.

    Note   You cannot relink a form if the all data in the form has been digitally signed (the form template has been configured for signing by using the Enable digital signatures for the entire form option, or by using the Enable digital signatures for specific data in the form option with the Set of signable data specified using an XPath expression of "/"). This is because when a form has been signed using this configuration the link to the form template is treated as part of the form data, and relinking would invalidate the signature. You can relink a form that has only part of the data signed (the form template has been configured for signing by using the Enable digital signatures for specific data in the form option with the Set of signable data specified as a subset of the data). For more information on using digital signatures, see Digitally Signing Data in InfoPath 2003.

    Here are the steps for performing a Relink operation:

    1. Open the new form library.
    2. Click Modify Columns and Settings to the left of the view.
    3. Under General Settings, click Relink forms to this form library.
    4. In the view presented, select all of the forms that you want to relink.
    5. Click the Relink button.

    The references in all of the forms you selected in step 4 will now point to the current form library location.

    Note   It is also possible to update the references in the form files using the Processing Instruction Update Tool provided with the InfoPath 2003 Software Development Kit (SDK); however in most cases the using the procedure above is simpler.

  • Microsoft InfoPath 2010

    Working with VSTO 2008 Projects in InfoPath 2010


    The InfoPath team is busy working on the next version of Office.  While we’re offline, we’d like to take the opportunity to tackle some of the questions that we get asked frequently by InfoPath users. 


     Today I’ll talk about how to migrate your InfoPath projects from Visual Studio Tools for Office 2005 or Visual Studio Tools for Office 2008 (VSTO) into InfoPath 2010 with Visual Studio Tools for Applications (VSTA).

     The decision to remove the ability to include InfoPath projects in professional developer solutions has been a controversial one, but is consistent with our overall message about SharePoint development – Create InfoPath forms with as little code as possible, and put the bulk of your code into middle tier services and workflows.

     That said, we frequently hear from users who invested in VSTO projects and need to know how to move those projects forward with InfoPath 2010 and Visual Studio 2010.  Here’s how.

     This walkthrough will demonstrate how to migrate InfoPath code projects from Visual Studio Tools for Office (VSTO), and into Visual Studio Tools for Applications (VSTA).

     First, ensure that VSTA is installed

     VSTA is an IDE included with InfoPath 2007 and InfoPath 2010.  The VSTA node is included in InfoPath 2010 setup.  Launch Office setup, choose to customize the install, and set Visual Studio Tools for Applications to ‘Run from my computer’.


    Next, migrate your project

    After installing VSTA, make a backup copy of your VSTO 2008 project that you will now proceed to migrate.

     Let’s walk through the conversion process of a VSTO 2008 project named “Hardware Order Form”. This project includes:

    1.       Custom classes used to create database connections and run queries. See DBConnection.cs.

    2.       External XML that are linked to the InfoPath data source. See Items.xml.

    3.       InfoPath form code. See FormCode.cs

    4.       References to non-default NETFW assemblies. See System.Windows.Forms and System.Data.

     Here is a screenshot of the Visual Studio project explorer to give an idea of the project structure:

    To migrate this project to VSTA

    1.       Launch Windows Explorer, and navigate to the InfoPath “manifest.xsf” for your project. This file is included in the “InfoPath Form Template” directory of your Visual Studio 2008 project by default.

    2.       You’ll see a list of files that directly correspond to the “InfoPath Form Template” directory shown in the VS Solution Explorer screenshot above. For example:

    3.       Right click “manifest.xsf”, and choose Design from the context menu

    4.       InfoPath 2010 Designer will launch.

    5.       Click the Code Editor button in the InfoPath 2010 Developer tab, and the browse dialog will appear



    6.       Click the Browse button, and navigate to the csproj file in the backup copy of your project. Select the csproj file and click ‘Open’.


    7.       VSTA will launch, and your project will be successfully migrated into InfoPath 2010 and VSTA.

     You can now work from within InfoPath 2010 and VSTA to code, build, and publish your solution.

  • Microsoft InfoPath 2010

    Cool Forms! Task Form


    This week’s cool form was submitted by Sean Cantellay of Cantellay Consulting. The form allows the user to select a SharePoint task from the right and view it in the form on the page. The task has been broken up into four views and the tab buttons moves the user through the different views. The user can also Escalate the task to another SharePoint group by clicking the Escalate button and selecting the group.

    Click on images for larger pictures.





    If you have a “cool” form that you would like to share with us, please send an e-mail with the following details to -

    • Attach 1 or 2 screenshots of your form
    • Provide a brief description of the form
    • You may also attach the XSN file (optional)

    The most popular submissions will be featured on our blog in future posts.

    Check out other Cool Forms here.

  • Microsoft InfoPath 2010

    Customize an External List Form in InfoPath 2010


    In this week's “5 for forms” video demo, Trey Brumley, a software design engineer in test shows how you can use InfoPath to customize the form for an external list on SharePoint that connects to a SQL Employee database through Business Connectivity Services.

    Get Microsoft Silverlight
  • Microsoft InfoPath 2010

    Cool Forms! Weather Forecast Form


    This week’s cool form displays your local weather forecast by using a REST Web Service data connection to pull in weather information from an online weather service. There are two views to the form, one minimal and one extended. The form contains linked picture controls that use rules to concatenate the Web service data and generate a URL pointing to images on the weather site. By hosting this form inside the InfoPath form Web part, you can display the latest weather forecast information on your SharePoint portal pages.

    Minimal View:





    Extended View:


    For more information about using REST Web Service data connections with InfoPath forms, see our earlier blog post

    If you have a “cool” form that you would like to share with us, please send an e-mail with the following details to -

    • Attach 1 or 2 screenshots of your form
    • Provide a brief description of the form
    • You may also attach the XSN file (optional)

    The most popular submissions will be featured on our blog in future posts.

    Check out other Cool Forms here.

  • Microsoft InfoPath 2010

    Displaying Contextual Help in a Custom Task Pane


    With all the wonderful features in the new Office apps, it's easy to get lost!  InfoPath is no exception, and when you make clever use of the new features, you'll want to make sure that users understand how your form is supposed to work.  Wouldn't it be great if you could display contextual help information as the user navigates to fields in your form.  With the "Context Changed" event, you can execute custom code when the user filling the form causes the context node to change.  This will fire when the user focuses a control bound to a different DOM node than the current context node.


    Files you'll need

    The solution we provide here uses some resource files.  Download the attached files to accomplish the scenario.

    1. "CustomTaskPaneHelp.htm" - The HTML file that will be displayed in the custom task pane.  We will manipulate this document at runtime from custom form code to display the contextually appropriate help information.  Just update the styles in this file to change the appearance of the contextual help in the custom taskpane.

    2. "Help Strings.xml" - This file is a basic xml file that contains mappings from local node names to the title and help contents for the node.  This file will be consulted to retrieve the help information to be displayed in the custom task pane.

    3. "CustomTaskPane.cs" - This helper class wraps the HtmlTaskPane object to access elements in the custom task pane.  This will be added to your VSTA project.

    4. "FormCode.cs" - This contains the code to integrate the custom taskpane into the form template.

    Note that this method works in InfoPath 2003 and 2007, but this tutorial will walk you through the steps in for InfoPath 2007 - the UI is slightly different in 2003, but you can still make it work. Since task panes are a rich-client only feature, this method is not supported in browser-enabled form templates.


    Construct your help resource file

    Assuming you've designed your form template already, you'll have a nicely populated data source, replete with variously named nodes.  Now add contextual help data for nodes in the main and secondary data sources:

    1. Open the "Help Strings.xml" file in notepad (or another text editor.)

    2. Add a "Help" element for the data source node:

    • Set the "nodeName" attribute's value to "<node prefix>:<Name in Data Source Pane>"
    • Set the "Title" element's value to the heading that you want to display for this node's contextual help.
    • Set the "Contents" element's value to the body of this node's contextual help.

    3. Repeat step 2 for all nodes for which you want to display contextual help so that you have something like this:

    <?xml version="1.0" encoding="utf-8" ?>
          <Help nodeName="my:TextField">
             <Title>Text Field</Title>
             <Contents>Help for my text field.</Contents>
          <Help nodeName="my:RichTextField">
             <Title>Rich Text Field</Title>
             <Contents>Help for my rich text field.</Contents>


    4. Save the file to a shared location

    NOTE:  If you want to be able to update this help data without having to re-deploy the form template, the shared location should be accessible to all users that will fill out the form.  If, on the other hand, you do not care about that, then you can just save the file locally and add it as a resource file to the form template.  See below…


    Add the data source that will provide your contextual help data

    Now that you're help strings are all set, we need to add a reference to the help strings so that the form template can access them.  We'll do this by adding a data connection to query the xml file from a shared location or resource file.

    1. Tools >> Data Connections >> Add

    2. Select Receive Data, then XML Document

    3. Specify the location of the help strings document (Help Strings.xml)

    • If, as noted above, you want to include the help strings as a resource file in the form template, just click "Next >". Including the file as a resource file guarantees that it will always be accessible to the form template, but the form template will have to be updated if you need to change the help strings.
    • If, on the other hand, you would like to access the help strings file from a shared network location or web server, then select "Access the data from the specified location" and then click "Next >". Accessing the file from a shared location may fail if the shared location is unavailable, and there may be some delay due to network traffic.

    4. Check the "Automatically retrieve data when form is opened" check box and click "Finish" / "Close".


    Enable the custom task pane in your form template

    Custom task panes are not enabled by default.  We'll specify that the custom task pane should be displayed, and its content should be rendered from the "CustomTaskPaneHelp.htm" file.

    1. Tools >> Form Options >> Programming

    2. Check the "Enable custom task pane" check box. Type a name for the custom task pane in the "Task pane name" field.

    3. Add the "CustomTaskPaneHelp.htm" file as a resource file.

    • Click Resource Files >> Add…
    • Browse to the "CustomTaskPaneHelp.htm" file and click Open / OK.

    4. Select "CustomTaskPaneHelp.htm" from the "Task pane location" drop-down list.


    Add the code to manage the context change and display the contextual help information

    1. Tools >> Programming >> Context Changed Event; this will create the VSTA project and insert the "Context Changed" event handler.

    2. Add the "CustomTaskPane.cs" file to your project

    • Right-click the top-level project node.
    • Click "Add" >> "Existing Item…"
    • Browse to the "CustomTaskPane.cs" file and click "Add".
    • IMPORTANT: Edit the Namespace of the "CustomTaskPane.cs" file to be the same as that of your form code file.

    3. Integrate the code in the attached "FormCode.cs" file into your VSTA project.  Make sure you copy the contents of the "FormEvents_ContextChanged" method, as well as the private properties and variables.

    4. Build and save your form template.



    Make the form template full trust

    1. Tools >> Form Options >> Security and Trust
    2. Uncheck the "Automatically determine security level" checkbox. Select the "Full Trust" radio button.
    3. Click "OK"
    4. Save and publish the form template. You will need to publish the form template as an installable form template (.msi) or digitally sign the template; detailed instructions are here.

    Now, when users fill out your form, contextual help will be displayed for each node as the user clicks on a control bound to it.  As long as you've included help information in the help strings file, you'll see the help information in your custom task pane!

    Forrest Dillaway
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    How to Integrate the .NET Framework SDK Documentation with VSTA


    The .NET Framework 2.0 SDK documentation includes the Visual Basic and Visual C# language references, as well as the documentation for the .NET Framework classes. You can download and integrate this documentation into the Help viewer for the Visual Studio 2005 Tools for Applications (VSTA) integrated development environment (IDE) that ships with InfoPath 2007. After doing so, the NET Framework 2.0 SDK documentation will be available along with the "InfoPath Developer Reference for Managed Code Form Templates" documentation in VSTA IDE Help viewer for use offline.

    .NET Framework SDK Help in the VSTA Help Viewer
    Important   If you are running under Windows Vista with user account control, you must start InfoPath 2007 as an administrator before performing the following procedure. To do that, navigate to C:\Program Files\Microsoft Office\Office12, right-click INFOPATH.EXE, and then click Run as Administrator. If you are not running InfoPath as an administrator, you will be unable to complete the following procedure.

    To integrate the .NET Framework 2.0 SDK documentation with the VSTA IDE Help

    1. Start InfoPath 2007, and open or create a form template in design mode.
    2. On the Tools menu, click Programming, and then click Microsoft Visual Studio Tools for Applications.
    3. In VSTA, click Index on the Help menu.
    4. Search for Collection Manager, Help, to open the Visual Studio 2005 Tools for Applications Combined Help Collection Manager topic.
    5. Select the check box for the Microsoft .NET Framework 2.0 SDK Documentation in the list of available help collections at the bottom of the topic below Collections available for the default combined Help collection.
      If the .NET Framework 2.0 SDK documentation does not appear in the list of available Help collections, you must install the .NET Framework 2.0 SDK. To install the .NET Framework 2.0 SDK, see
    6. Click the Update Help Collection button.
    You will be asked to close all instances of the VSTA IDE and the Help viewer, Microsoft Document Explorer. When you restart VSTA, the.NET Framework 2.0 SDK documentation will be available in the Help viewer.
    - Mark Roberts, Programmer-writer
  • Microsoft InfoPath 2010

    Implementing Roles in Browser Forms


    What are Roles? Without going much in detail, InfoPath roles is a functionality where you can define user tags like "Sales", "Management" and utilize them in your form logic. This enables some very interesting scenarios in the forms space. For a detailed discussion on this topic, take a look at this MSDN lab. If you have worked with InfoPath 2003, you would notice that Roles have not changed much in 2007, and that they are not supported by InfoPath Forms Services. My focus will be in how we can enable role-related scenarios in browser forms.

    For the purpose of this article, lets borrow the scenario from the lab. - "The management team at Contoso Corporation reviews each of the Sales Report filled out by sales representatives. Because the management team is interested only in sales deals that exceed a certain amount of money, your department is asked to add an additional view to the sales form that shows only those deals"


    STEP 1: Find a way to store role-related data

    You can store information about which users belong to which grounps in an XML file, included as resource as a part of the XSN. Here's one way to organize this XML file:


    <?xml version="1.0" encoding="utf-8"?>

    Create a data source pointing to this resource file and use this data source to make decisions in step 2.

    Variation: Roles and Users relationship might be stored in a database (say HR system). You would then create a secondary data source connecting to your HR System instead of the XML file mentioned above; everything else stays the same.

    STEP 2: Determine the role of the current user

    1. Add hidden fields to the main data source of your form. These will store:

    • Active Directory username (alias) of the currently logged on (let's call the field CurrentUser)
    • Role of the current user, as determined by our form logic (let's call the field CurrentRole)

    2. Set the detault value of CurrentUser to the username() function.

    3. Set "CurrentRole" value to

    name[username = CurrentUser]


    STEP 3: Use rules and CurrentRole

    To accomplish our scenario, we will create two views: one for "Sales", and one for "Management". Using Rules, you can switch to the appropriate view on load of the form:

    1. With the form template in design mode, on the Tools menu, click Form Options.
    2. Click the Open and Save tab, and then click Rules, and the following two rules:

    • If CurrentRole = "Sales", switch the view to the Sales view.
    • If CurrentRole = "Management", switch the view to the Management view.

    And that's it! You can use CurrentRole the same way you'd have used Roles in the InfoPath smart client. Note that this trick works on the smart client, too - so if you want to create a roles-based InfoPath application, this method will help.

    Pradeep Rasam
    Program Manager

  • Microsoft InfoPath 2010

    Creating Complex InfoPath Controls in C#


    One of the problems with InfoPath controls is their limited availability. For example, there is no such control like the NumericUpDown control in WinForms. Or you may have a predefined complex UI, which you want use multiple times.

    In these circumstances, what we need is a mechanism for control extensibility. Today, InfoPath provides two different control extensibility mechanism: Template parts and ActiveX controls.

    Basically, template parts are predesigned InfoPath form templates, that can be imported into other templates. This mechanism provides a good way of reusing the same controls again and again, but on the dark side, you are still restricted with the control set of InfoPath.

    Other mechanism, which is extensibility via ActiveX controls lets you go beyond the control set of InfoPath and use whichever ActiveX control you want. In this blog, we will drill down into using a Windows control in InfoPath forms, and more importantly provide a way of binding data to these controls. This blog will give details of using WinForm controls that are registered for COM Interop, inside InfoPath forms. Two mainly used types for binding ActiveX controls to InfoPath data sources are 'Simple Binding', ‘Stream Binding’ and 'Node Binding'. In this article we will cover node binding. You can find more information about types of binding between ActiveX controls and InfoPath data source here:


    Simple Binding

    If your external control needs to be bound to a single field in InfoPath main data source, then you can use single binding between your ActiveX control and data source. An excellent simple binding example by InfoPath team can be found here: Creating an InfoPath Custom Control using C# and .NET. I highly recommend you to read this article first both to understand how to register our Windows Forms controls for Com Interop, and how simple binding is done for a primitively typed single field. Rest of the article will assume you read and applied the principles told in this article.

    Node Binding

    When binding to a single field or attribute is not enough, or you need your ActiveX controls to interact with data coming from different fields, node binding is the way to go. A classical example would be an ActiveX control capable of showing an Address type complex structure composed of Street, City, State and ZipCode fields.

    In this case, you need an Xml node in InfoPath form template as a data source that obeys the schema of Address object.

    InfoPath form

    We will design the data source of InfoPath first. Let's just write a schema file that corresponds to the structure of Address class. A simple schema file just including address data would be similar to this:

    <xsd:schema xmlns:xsd="">

          <xsd:element name="fields">



                            <xsd:element ref="address" minOccurs="0"/>




          <xsd:element name="address">



                            <xsd:element ref="street" minOccurs="0"/>

                            <xsd:element ref="city" minOccurs="0"/>

                            <xsd:element ref="state" minOccurs="0"/>

                            <xsd:element ref="zipCode" minOccurs="0"/>




          <xsd:element name="street" type="xsd:string"/>

          <xsd:element name="city" type="xsd:string"/>

          <xsd:element name="state" type="xsd:string"/>

          <xsd:element name="zipCode" type="xsd:integer"/>


    Start to design a new InfoPath form template from XmlSchema and use this schema as your source. InfoPath should parse the schema, and should create the data source entries in Data Sources tab in design task pane for you. At this point, let's create 4 text boxes that will display each of these fields. For the educational purposes of demo, do not drag and drop the whole address node onto the surface. Instead, drag and drop individual fields on to the design surface. This is because, after designing the ActiveX such that it is bound to whole DOM node, we will get a binding structure like this:



    Since we finished the main part of the form template, let's start to prepare the ActiveX object that we will use in the template. Assuming you read the article Creating an InfoPath Custom Control using C# and .NET, I will just touch the points not told there.

    Design the control
    Simply drag and drop four Labels and four TextBoxes on to the user control for each of the fields in Address type.

    Register for ComInterop

    As told in the article, we will need a Guid attribute for Visual Studio to register the control for Com Interop. What is not told in the article is, we need one more attribute to be able to register the control via Visual Studio: ComVisible. Although, UserControl class is donated with ComVisible(true) attribute in .Net framework, we have to state it explicitly one more time, because ComVisible attribute is created with AttributeUsage(…, Inherited = false), which prevents the value of the attribute to be inherited to children classes. So, our control should look similar to this for a successful registration:



    public class ComplexUserControl : UserControl

    After building this code, a quick search through registry for Guid, will prove that class is really registered.

    You should import the IObjectSafety interface exactly as told in the article. Before discussing IPropertyNotifySink, let's first take a look at the control interface, that will define the Value and Enabled property. In simple binding example, we had a primitive property in ICOMControl interface. Since we are no longer binding to a primitive field, we have to define a new interface.

    Let's define an IComplexControl interface similar to IComControl interface in the article. For Value property, we will use IXMLDOMNode type defined in Microsoft.Office.Interop.InfoPath.Xml.dll assembly that you will find in your Office 12 installation directory. This corresponds to a node in InfoPath main DOM data source. At the end, our interface should be similar to this:


    public interface IComplexCOMControl



        IXMLDOMNode Value { get; set; }



        bool Enabled { get; set; }


    As stated in the article, Constants.DISPID_VALUE should be 0, and Constants.DISPID_ENABLED should be 1, in order for InfoPath to correctly communicate with our control.

    Now let's inspect IPropertyNotifySink interface. One of the main differences between Simple Binding and Node Binding is the type of the Value property. Simple binding deals with primitive types, whereas node binding deals directly with DOM. In simple binding a rough sequence of events would be like this:

          Property change in data source --> … -->Set Value property of ActiveX

    And the other way around:

          Property change in ActiveX --> Raise OnChanged -->InfoPath queries for Value property --> … -->Set Value property of ActiveX

    However, since InfoPath sends the whole DOM node as our Value property by reference, we don’t need to set an intermediary Value property. Instead we can directly change DOM values from DOM node reference. So we can safely ignore RaiseOnChanged and InfoPath queries for Value property steps. Since IPropertyNotifySink interface is used mainly for property change notification purposes will not implement it in this demo. If you care about Enabled property changes, you still have to implement this interface and notify InfoPath when Enabled property changes.


    Value property implementation

    When InfoPath first calls the setter of Value property after instantiating our control, it will pass in the IXMLDOMNode representing the main DOM of InfoPath. We have to keep this node in our control, in order to be able to change the data values corresponding to changes in UI.

    In the getter of the property, since we are not changing the reference of DOM node, it is safe to return this kept value.
    Whenever some field (or subfields in our group field)changes in DOM, InfoPath will call the setter of our Value property. In the setter, we should query the DOM according to XPaths of our fields, and then update the UI according to the values if necessary. At the end, our Value field should look like this:

    private IXMLDOMNode domNode = null;

    public IXMLDOMNode Value




          return domNode;




            if (domNode != null)


                ChangeUI(streetTbx, domNode.selectSingleNode("/fields/address/street").text);

                ChangeUI(cityTbx, domNode.selectSingleNode("/fields/address/city").text);

                ChangeUI(stateTbx, domNode.selectSingleNode("/fields/address/state").text);

                ChangeUI(zipCodeTbx, domNode.selectSingleNode("/fields/address/zipCode").text);





    private void ChangeUI(TextBox tbx, string text)


       if (tbx.Text != text)


        tbx.Text = text;



    At this point we have completed the one direction of binding, originating from data source and going to UI. Now, let's handle the other way around, from UI to data source. In order to do this, we have to create a simple event handler that will catch change events in UI. Then register for all four text boxes' TextChanged events, such that each of them will be handled by this event handler. Code should look like this:

    public ComplexUserControl()




        // Register for UI change events

        this.streetTbx.TextChanged += this.HandleChangesInUI;

        this.cityTbx.TextChanged += this.HandleChangesInUI;

        this.stateTbx.TextChanged += this.HandleChangesInUI;

        this.zipCodeTbx.TextChanged += this.HandleChangesInUI;



    private void HandleChangesInUI(object sender, EventArgs e)


        TextBox senderTbx = (TextBox)sender;

        if (senderTbx == this.streetTbx)

            this.ChangeDOM("/fields/address/street", this.streetTbx.Text);

        else if (senderTbx == this.cityTbx)

            this.ChangeDOM("/fields/address/city", this.cityTbx.Text);

        else if (senderTbx == this.stateTbx)

            this.ChangeDOM("/fields/address/state", this.stateTbx.Text);

        else if (senderTbx == this.zipCodeTbx)

            this.ChangeDOM("/fields/address/zipCode", this.zipCodeTbx.Text);



    private void ChangeDOM(string xPath, string value)


        if (domNode != null)


            IXMLDOMNode singleNode = domNode.selectSingleNode(xPath);

            if (singleNode.text != value)


                singleNode.text = value;





    In order to be able to use the ActiveX Control in the design of a form template, we have to make one final trick: Placing the .ict file that describes the control and its binding, to our controls directory. In order to add custom controls design task pane in InfoPath, generally you first go to the Controls tab, then click Add or Remove Custom Controls at the bottom of this tab, select to add a new ActiveX control, and finally select the ActiveX you want to add from the list of registered controls. If you have ever done this before, there should be a directory named

    C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\InfoPath\Controls

    In this directory there should be a .ict file for each of the ActiveX controls that you have done this operation for. We have to create a new .ict file for our control. If above directory does not exist, create it. Then create a file with name "{yourClassGUIDHere}.ict". This file should be in this format:

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>

    <ict:control name="Complex C# Control, v1.0" xmlns:ict="" xmlns:xsd="" xmlns:xdSdl="" xmlns:ict2="ict2" xmlns:xd="">





                <ict:controlPackage classid="{yourClassGUIDHere}"/>



                <!--default shape-->






               <ict:controlObject bindingProperty="Value" bindingType="xmlNode" enabledProperty="Enabled" enabledValue="true"/>



    Note the bolded text. You should place the correct GUID for your control, and note that we are actually specifying 'xmlNode' as bindingType. Rest of the file is almost standard except the iconBitmap part, which specifies the icon that will be displayed next to your control in design task pane.

    Since we have a ready control now, we can safely use it in our form template. Open the InfoPath form you have designed in design mode again. Go to Controls tab in design task pane. At the bottom, under Custom section, you should see the 'Complex C# Control, v1.0' with icon I have copied from Microsoft Forms Progress Bar control. Drag and drop this control to design surface. According to your security settings, it may ask you if you want to run ActiveX control. If so, press 'Yes' and continue. Since we have already defined a data source in the form, InfoPath will ask which field or group do we want our control to bind to. Choose address here. Now you should see the control on the surface, and its binding field is specified as /fields/address. Press Ctrl+Shift+B to preview the form. You should see the corresponding InfoPath TextBoxes and our UserControl's TextBoxes are synchronized, because they are bound to same data source fields.

    Now we have a functional complex WinForm UserControl, that we can display in an InfoPath form template, and even better, this UserControl is bound to InfoPath main DOM.

    Improving ActiveX Discrepancies

    If you played with the form a few minutes, you must have noticed that there is something weird going on. If you are changing the text value of InfoPath TextBoxes, you see a flicker in the UserControl before data is reflected to it. Similarly, if you change the value of a TextBox in your UserControl, you also see a flicker in the UserControl, and focus is continuously given to first TextBox added to UserControl.

    Main reason for this issue is, whenever a data field that is bound to your ActiveX is changed, InfoPath destroys your control and create a new one. This is mainly because InfoPath has to apply your view xsl to your data source to create the view you see on the display. Every time data source changes, InfoPath re-applies the xsl file and creates the view from scratch for controls that are bound to changed data fields. If you are debugging the form, you can easily see this by putting a breakpoint in the constructor of UserControl. Clearly, this leads us to write stateless controls, since each time the controls are destroyed, state is destroyed too. Or, as a second approach, we can take advantage of a helper interface, InfoPathControl interface, to save the state to some persistent storage just before destruction, and retrieve it after re-creation. Let's inspect how this approach works.

    InfoPathControl interface is defined in Microsoft.Office.Interop.InfoPath primary interop assembly. Add a reference to this assembly to your project and implement the interface on your UserControl. I advise you to read the explanation of all four methods of the interface, and how they are used in MSDN. Here, we will only concentrate on two of them, which are Init and SaveState methods.

    SaveState is called by InfoPath, just before the destruction of the older control, which makes it a perfect point to save the state to some storage. Init is called after creating the new control, which lets us to use it to retrieve the saved state and apply it to our control.

    Init method takes a parameter of type InfoPathControlSite. This interface gives us the main DOM node and XDocument of InfoPath form template, which basically enables us to access pretty much all of the object model of InfoPath. So, we don't have to wait for the setter of Value property anymore. We can cache the domNode here in Init method. We will also cache the XDocument for storing the state in, since we will need a persistent storage for our state while we are destroyed. In general, Init method body should be similar to this:

    private XDocumentClass xDocument = null;

    public void Init(InfoPathControlSite pControlSite)


      this.domNode = pControlSite.Node;

      this.xDocument = (XDocumentClass)pControlSite.XDocument;



    We will inspect RestoreState method after SaveState method.

    For simplicity, we will assume that we only want to keep which control has the focus in UserControl and give focus to that control after re-creation. Saving the name of the active control should be enough for state restoration. In reality in a control like this we should also keep the location of the cursor inside the TextBox as well as which TextBox is active.

    We said that we will use XDocument to save the state. This is because XDocument lives with the form template, so it is persistent during the lifetime of our control, and XDocument has a property bag that we can use for this purpose. We can update this property bag by calling SetNamedNodeProperty and querying it by calling GetNamedNodeProperty method on XDocument object. At the end, SaveState and RestoreState methods should be similar to this:

    public void SaveState()


        if (this.xDocument != null)


            this.xDocument.SetNamedNodeProperty(this.domNode, "ActiveControl", this.ActiveControl.Name);




    private void RestoreState()


        if (this.xDocument != null)


            Control activeControl = this.Controls[this.xDocument.GetNamedNodeProperty(domNode, "ActiveControl", this.Controls[0].Name)];

            if (activeControl != null)






    In the call to GetNamedNodeProperty in RestoreState method, third parameter is the default value, which will be returned back if specified property name can't be found in property bag. This will be the case when control is first created.

    Now, each time data source has changed, we save which control was active in UserControl before it is destroyed. Then InfoPath instantiates a new instance, we restore the state if there is any. Then InfoPath sets the Value property with updated fields.

    Saving the whole state in a WinForm control is a non-trivial task and maybe somewhat cumbersome. I'm optimistic about this re-creation of ActiveX controls will be optimized by InfoPath team in the next release.

    At the end, our code will look like this attached file.

    Deniz Demircioglu
    Software Design Engineer

  • Microsoft InfoPath 2010

    Data binding between Document Information Panel and Word document

    The Document Information Panel is a Microsoft Office InfoPath 2007 form that is hosted and displayed in a Microsoft Office Word 2007, Microsoft Office Excel 2007 or Microsoft Office PowerPoint 2007 document. It enables users to view and edit properties of a document or a content type that is associated to a document management server.
    In Microsoft Office Word 2007, users can add properties from Document Information Panel as content controls to document surface. This is also known as data binding between Document Information Panel and Word document. Users can bind Document Properties, Server Content Type Properties or Custom Properties. Once the data is successfully bound, users can edit the properties from Word document surface.
    This article will demonstrate two ways to bind data from Document Information Panels to Word document surface.
    Method 1: Binding Document Properties or Server Content Type Properties to document surface
    1. Launch Office Word 2007
    2. File | Open to open any Document Information Panel document
    3. Place IP in the document where you want the property control to be
    4. Click Ribbon UI Insert | Quick Parts | Document Property
    5. Choose the property you want to add:

    You now have a content control in Word surface that binds data to Document Information Panel property. Please note that this method also works for Server Properties, but you need to save or associate the document with the Server document library first. Then you will see Server Properties in Quick Parts | Document Property list.
    Method 2: Binding Custom Properties to document surface
    For non-document or non-server related properties, which are defined as Custom Properties in this blog, there is no UI to bind these properties directly to document surface. Users need to use Word Object Model to do the data binding.
    Assume the Custom Document Information Panel has the following data structure:
    Here are the steps to bind the costCenterID property to Word document.
    1. Launch Microsoft Word 2007
    2. File | Open to open a document that contains this custom Document Information Panel
    3. Press Alt+F11 to launch Microsoft Visual Basic editor
    4. Press Ctrl+G to launch the Immediate window
    5. In the Immediate window, add a Text content control by triggering the following command:
    ActiveDocument.ContentControls.Add wdContentControlText
    1. Set up this content control XML mapping to costCenterID node by triggering the following command:
    ActiveDocument.ContentControls(1).XMLMapping.SetMapping "//*[local-name(.)='costCenterID']",, ActiveDocument.CustomXMLParts(4)
    Here the SetMapping function takes three arguments. First input is the XPath of the node you plan to do a mapping.  Second one is PrefixMapping input. Last one is Custom XML Part source where the node belongs to. In this case, costCenterID node lives in 4th custom XML part.
    1. Switch back to Word active document window. The content control should get set up.

    Now you have successfully set up properties mapping between Document Information Panel and Word document. When you edit the properties from Word document, the value is updated in the Document Information Panel automatically or vice versa.
    If you'd like to know more about the Document Information Panel, be sure to check out this webcast.
    Emily Ching
    Software Design Engineer in Test
  • Microsoft InfoPath 2010

    New InfoPath content on the web


    I wanted to take a moment to recognize the great work of the Microsoft writers and editors who have been cranking out InfoPath content over the last few months.  While we in the product team have clicked over into Office 14 mode, they have continued to serve customers by creating Office 2007 content – everything from video demos to highly technical developer content.  Here’s some of the content that has been released since RTM.  Thanks to Anneliese Wirth, Arsenio Locsin,  Amy Miller, Anthony Labriola,  Kelley Vice, Tonda Kiffin, David Longmuir, Roger Haight,  and Mark Roberts for getting this information into the documentosphere!



    November 2006:

    -          Demo: Convert a Word document into an InfoPath 2007 form template

    -          Demo: Use InfoPath e-mail forms to view data in Outlook 2007

    -          Demo: View the business logic in an InfoPath 2007 form template


    April 2007:

    -          Article: How to: Share InfoPath 2007 Template Parts and ActiveX Controls

    -          Article: Hosting the InfoPath 2007 Form Editing Environment in a Custom Web Form


    May 2007:

    Article: How to: Evaluate and approve a form template

    Article: Guidelines for Creating InfoPath 2007 Converters


    June/July 2007:

    -          Article: Working with XML Data Using the XPathNavigator Class in InfoPath 2007 Form Templates

    -          Article: Guidelines for using colors, fonts, and images in a form template

    -          Article: Converting InfoPath 2003 Managed Code to the New InfoPath 2007 Object Model


    In addition some content that has been missing from MSDN has been re-published:


    -          InfoPath 2003 SDK:

    -          InfoPath 2003 technical articles:


    We also have some excellent articles written by David Gerhardt of 3Sharp

    -           Developing InfoPath 2007 Managed-Code Solutions.

    -          Pulling CRM Data into InfoPath 2007 Browser Forms 


    And finally, InfoPath MVP Ben Walters just posted a code sample which shows how to limit the contact selector control to  single selection:



  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 6)


    Part 6 – Addendum: Links to related performance resources

    Welcome to the sixth article in our series about designing InfoPath browser-enabled forms for better performance and scalability. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. We also described some of the issues that affect form-rendering performance in the browser and suggested using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer. Finally, we listed some useful performance monitoring counters available in PerfMon.

    In this addendum, we list a variety of links to additional resources you might want investigate if you are interested learning more about designing forms with InfoPath 2007. In keeping with our theme, the emphasis is on performance, but you will also find other related resources that you can use to broaden your understanding of the online forms environment. Since InfoPath is built on SharePoint technologies, the following resources provide information not only on InfoPath Forms Services and browser-enabled forms, but also SharePoint, ASP.NET, and SQL Server. In addition, we’ve included some general resources on monitoring and testing, and thrown in a few good blogs as well.

    Hope you’ve found this series helpful in demystifying InfoPath browser-enabled forms performance. Be sure to let the InfoPath team know if you have comments or questions about your own forms requirements by adding comments here or on the InfoPath newsgroup listed below!


    Brad Valantine
    Technical Writer


    Improving the Performance of InfoPath 2007 Forms
    A whitepaper about performance and the InfoPath rich client. Because of differences between the client and browser-enabled forms, not everything applies to Forms Services and browser forms, but a must read nonetheless.

    InfoPath Forms Services best practices

    Microsoft Office Forms Server TechNet TechCenter

    InfoPath Forms Services roadmap

    InfoPath 2007 features that are unavailable in InfoPath Forms Services

    Forms Server 2007 Home Page

    InfoPath 2007 Home Page

    Planning and architecture for Office Forms Server 2007

    Plan InfoPath Forms Services

    Office Developer Center: InfoPath 2007 Resource Center

    InfoPath Forms Services Architecture

    Form Development and Deployment Lifecycle

    Creating InfoPath Form Templates That Work With Forms Services

    Support: Microsoft Help and Support: Forms Server 2007 Solution Center


    Plan for performance and capacity (Office SharePoint Server)

    Plan for performance and capacity (Windows SharePoint Services)

    White paper: Intel Performance Testing of Windows SharePoint Services (WP)

    How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance

    White paper: Planning and Monitoring SQL Server Storage for Windows SharePoint Services: Performance Recommendations and Best Practices


    ASP.NET Performance

    ASP.NET Session State Overview

    Developing High-Performance ASP.NET Applications

    Monitoring ASP.NET Application Performance

    SQL Server

    Performance (Database Engine)

    Monitoring (Database Engine)

    Monitoring and Testing

    Life-Cycle Performance Testing for Eliminating Last-Minute Surprises

    Server Performance and Scalability Killers

    Performance Counters in the .NET Framework


    Designing Forms for Microsoft Office InfoPath and Forms Services 2007 (Microsoft .NET Development Series)
    By Scott Roberts and Hagen Green
    Publisher: Addison-Wesley (c. 2007)
    ISBN 0321410599

    A couple of great online books from the folks in Patterns and Practices:
    Improving .NET Application Performance and Scalability

    Performance Testing Guidance for Web Applications


    Blogs and Newsgroups

    Pashman's InfoPath Goldmine: Tips and Tricks for Tuning Forms Services Performance

    Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests
    The first article in a series about research done by Yahoo into web page performance optimization.

    Agile Testing: Performance vs. load vs. stress testing

    Ben Curry: Using Performance Monitor (perfmon.exe) to Monitor SharePoint Server 2007

    Ben Curry: SharePoint Server 2007 Performance Counters

    Thom Robbins .NET Weblog: InfoPath Tips and Tricks

    Joel Oleson's Blog - SharePoint Land:
    Performance & Scale

    Good List of Performance Counters

    S.Y.M. Wong-A-Ton: Enterprise Solutions

    Paul Vick - Panopticon Central: The Ten Rules of Performance

    Technorati - infopath Blogs, Photos, Videos and more on Technorati

    Discussions in Infopath General Questions
    Use this newsgroup to communicate with the InfoPath community.

    MSDN Forums: SharePoint - InfoPath Forms Services
    This forum is another place you can ask questions about Forms Services.


  • Microsoft InfoPath 2010

    Consuming Excel Data using InfoPath Database Data Connections


    InfoPath data connections can be one of the most powerful features of the product.  However, sometimes the out-of-box support for various data sources just doesn't seem to cut it when you get out into the field.  How in the world can I get data from an Excel spreadsheet  into my InfoPath form?  A typical response might include externally automating Excel via COM or the managed PIA to create InfoPath forms.  Or you might try using the Excel 2003 XML spreadsheet file format with the InfoPath XML data connection.  While both solutions are feasible, they can be a bit clunky to manage multiple files generated from your spreadsheet…
    Here is your question answered!  Access 2007 provides support for linked tables, virtual tables that pull data from a data source external to an Access database.  Since InfoPath has a built-in database data connection that can query data directly from an Access database, Access 2007 can effectively act as a router for data sources that aren't directly supported by InfoPath.  In this post, we'll step through setting up an InfoPath database data connection that queries data from an Excel spreadsheet.
    Prepare your Excel spreadsheet
    Once you've added all the necessary data to your Excel spreadsheet, save the Excel workbook to a shared network location that will be accessible to all users filling out your InfoPath form.
    Create the Access database to link the Excel data
    Launch Access 2007 and create a new blank database.  When you create a blank database, a default table will be created.  Go ahead and delete the table (just closing the query view should remove the table.)
    Switch to the "External Data" tab in the Ribbon


    Click the "Excel" icon in the "Import" chunk to launch the "Get External Data - Excel Spreadsheet" wizard.
    Browse to the Excel workbook that you saved in the "Prepare your Excel spreadsheet" section, above.
    Select "Link to the data source by creating a linked table" and then click "OK".


    Choose the Sheet or Named Range that you want to import, then click "Next >". If the first row of the spreadsheet contains column headers, check the "First Row Contains Column Headings", then click "Next >".

    Type a name for the linked table (I'll call it "Spreadsheet" for this post), then click "Finish".
    Click "OK" when Access tells you it's done linking the table.  When the dialogs close, you'll see the linked table listed in the "All Tables" task pane


    Save the Access database to the same directory where the Excel file was saved, then close Access.
    Design the InfoPath Form Template to Query the Linked Table
    Design an InfoPath Form Template based on a "Database" (you could also add the data connection as a secondary database data connection in an existing form template).


    Once you've clicked "OK", the "Data Connection Wizard" will open.  Click "Select Database…" to open the "Select Data Source" file browser dialog.

    Click "New Source…"

    NOTE: At this point, it's tempting to just browse to the Access database as you normally would.  However, the default provider used in that case does not support linked tables, so InfoPath will see no tables in the database.  In order to select the appropriate provider, you have to click "New Source…"


    Select "ODBC DSN", then click "Next >".
    Select "MS Access database", then click "Next >".

    Browse to the Access database that you created in the "Create the Access database to link the Excel data", above, then click "OK".

    NOTE:  This browse dialog can be a bit confusing.  If you get mixed up by the unusual browsing experience, you can just type or paste the full path to the database in the "Database Name" field (boxed in green in the screenshot below).


    Select the name of the linked table, then click "Next >"
    Finish the data connection wizard as you would for any other database data connection.
    At this point, you're good to go.  The data connection to your Excel data will behave the same as a query-only Access database data connection.

    - Forrest Dillaway, InfoPath Test


  • Microsoft InfoPath 2010

    We want to see your Cool Forms!


    Today sees the launch of “InfoPath Cool Forms”. In this series, we will feature cool forms that showcase a form design practice or interesting scenario.

    This week’s cool form is the “Ask Kanesha” request form.  This is a neat little form that we use on the InfoPath team to submit requests to our Group Business Administrator, Kanesha.

    Ask Kanesha

    Kanesha was being flooded with requests from team members and tracking all these requests was becoming a challenge. To help manage the requests, we created an ‘Ask Kanesha’ InfoPath browser form that submitted all requests to a SharePoint list. Team members use this form to submit requests. A simple workflow fires alerting Kanesha to the new request. Certain requests such as those for small hardware can be completed in minutes. The dropdowns in the form automatically filter to guide us to the right hardware. Other custom requests may take longer and can be managed by Kanesha online. The form saves us time and helps Kanesha keep track of all the requests that come her way.

    If you have a “cool” form that you would like to share with us, please send an e-mail with the following details to -

    • Attach 1 or 2 screenshots of your form
    • Provide a brief description of the form
    • You may also attach the XSN file (optional)

    The most popular submissions will be featured on our blog in future posts.

    Check out other Cool Forms! here.

  • 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

    Extending the InfoPath control set with custom controls

    InfoPath provides a rich and complete set of generic built-in controls in both 1.0 and SP-1, but there are some cases where there is a need for a control that is specific to your form or to your organization.  InfoPath SP-1 provides functionality to let users extend the set of controls available. Form developers can leverage currently existing ActiveX controls and use them within InfoPath. Also, following a few prescribed steps, software developers can write their own ActiveX controls to be used in InfoPath.

    InfoPath’s custom control support allows users to create controls for three different types of binding:

    Simple data type (string, numbers, etc)

    Controls that are written to bind to simple data types would allow a control to do custom processing on data before it gets put into the XML. The control can be designed to have UI that combines multiple simple controls (buttons, textboxes, checkboxes, etc…) to encapsulate them into one control. For example, multiple buttons can be combined with a textbox to make an in-document calculator control. Combining these all into one control will provide a simple way to re-use the same control in multiple forms.

    XML stream

    InfoPath SP-1 allows XML nodes to follow any schema. This allows form developers to work with industry standard XML Schemas. One example is a MathML control that could be written for InfoPath to save XML compliant with the MathML schema and display it in InfoPath form in a meaningful manner.


    For greater flexibility, InfoPath custom controls can be bound to an IXMLDomNode and any msxml operations can be performed directly on the XML tree.


    Custom controls need not be installed on every form users’ computer before loading the form. Controls can be packaged with your form solution so that on first open, the control will be registered and installed. Controls should be stored in a CAB files and able to self-register.


    Custom controls in InfoPath have a few security constraints to keep users safe. Firstly, all custom controls used within InfoPath require the IObjectSafety interface to be implemented and the control to be marked as Safe for Scripting and Safe for Initialization. Without these two flags, InfoPath will not load the form and will notify the user.

    In addition, for solution which have controls packaged in the form solution, it is necessary to sign the CAB files with a digital signature. When users open the form for the first time, they will be prompted on whether or not they will accept the control signed with that signature (similar to the ActiveX control dialogs you see in Windows 2k/XP).

    For detailed information on how to write a custom control for InfoPath, see Lab 06 in the MSDN InfoPath 2003 Training. (


  • Microsoft InfoPath 2010

    Modifying InfoPath manifest.xsf file from script (1/5)


    In this five part series we’ll show the reader how to programmatically manipulate InfoPath form templates.

    Part 1 of 5: The story

    There are many scenarios where you might need to modify an InfoPath form template (.XSN) after it’s already in use. Let’s say the URL of your Web Service changes.

    With InfoPath 2003 you need to change the URL manually:

    1. Open the form in design-mode (e.g. Right-click on the XSN and select Design).
    2. Extract files of the form template (XSN) into the temporary directory using File | Extract Form Files…, then close InfoPath
    3. Find manifest.xsf in the directory and open it in Notepad (or some other text editor).
    4. Find and replace all instances of existing URL with the new one.
    5. Save the modified manifest.xsf.
    6. Right-click the modified manifest.xsf, select Design, and finally use File | Save As... to save the form template as a XSN file.

    With InfoPath 2003 with Service Pack 1 (SP1), just open the form in Design mode, go to Tools menu, select Change Data Source, and in the wizard locate the new URL.

    But this isn’t (just) a sneaky way to convince you to download the SP1 Preview.

    What if you are responsible for maintaining hundreds of InfoPath forms which rely on the Web service? Even with SP1 this would be a lot of work. It would be nice to do it programmatically.

    The good news is that this is possible, even without SP1. The InfoPath XSN format is really a CAB file, and the files that make up the template are XML files which can easily be modified programmatically. You can pack/unpack a CAB file with help of extract.exe and makecab.exe utilities that are accessible for Windows users. Now the only things you need is to implement a small utility using script or managed code that will do the described above sequence automatically. Inside of the utility you should do the following:

    1. Unpack XSN file using extract.exe utility to the local temporary directory.
    2. Find manifest.xsf file and open it as a plain XML file.
    3. Replace the corresponding URLs using the XML DOM.
    4. Save the modified manifest.xsf.
    5. Pack all files into the XSN using makecab.exe utility.
    6. Clean up your temporary directory.

    If you write a wrapper around this process to enumerate all the form templates, your hundreds of forms will be updated just in a few minutes.

    Using this approach you can change not only URLs but SQL connection strings, files names, etc. If you want to learn more about the XSN format and the files that make it up, check out the InfoPath 2003 SDK. As always, be careful – save backup copies, test your code, test the templates before and after, etc.

    At the end of this discussion, the patient reader expects a good sample that supports the idea explained above. And we will definitely do it in the following parts 2-5 of the series.

    To be continued.


Page 4 of 12 (298 items) «23456»