Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    SPC Recap: Create Form Driven Mashups with the InfoPath Form Web Part


    The recent SharePoint Conference ended with a bang as Nick Dallett showed participants how they could create rich enterprise mashups by using InfoPath to create dynamic web parts without writing code.

    Nick showed off the new InfoPath form web part and demonstrated how easy it is for business users to use the web part to create composite applications together with other web parts that ship out of the box in SharePoint 2010, as well as custom web parts created by developers.

    Nick started by defining what an enterprise mashup is, pointing out three key points:
    - They are created by *business users*, not IT
    - They feature one or more sources of enterprise and public data
    - They provide visualizations of that data which helps users make better, faster, and more efficient decisions.

    He then went on to present 9 different scenarios where InfoPath was used as part of an enterprise mashup.  Each mashup illustrated a slightly different angle of the two design patterns that underlie all of the examples:

    1. The Connection-oriented design pattern, where web parts communicate using part-to-part connections, and
    2. The List-oriented design pattern, where web parts communicate by virtue of the fact that they are connected to one or more related lists

    1. Channel Analyzer (IDV Visual Fusion)
    (Design pattern 2 – list-oriented)

    Litware Channel Analyzer Application 

    IDV Solutions Logo

    Scott Caulk from IDV solutions ( gave a brief demonstration of an application built on their Visual Fusion product.  Visual Fusion is a rich Silverlight-based web part which allows users to aggregate multiple sources of data from the enterprise or the web, and visualize it in Bing maps.  Scott showed how a marketing manager for Litware books can use sales data plotted on the map to determine where a new promotional event may have the most impact.  The manager then clicks a button to fill out an InfoPath form to schedule a new marketing event.  Once submitted, data about all marketing events that have been scheduled is displayed on the map alongside the sales data.

    2. Customers and orders
    (Design pattern 1 – connection-oriented)

    Customers and Related Orders 

    Nick had some fun with the next two demos, which center around Contoso Office Supplies, where Nick moonlights as a salesman (wink wink).  After showing us the custom InfoPath form that he uses to display data from his customer list, Nick’s cell phone rang on stage, and after a brief moment of confusion (is he really going to answer a call in the middle of a presentation??), Nick let us know that the call was from Karie, the office manager over at Fabrikam.  It was all part of the show!   Karie wanted to know what pending orders she had so that she could put together the order for this week.  Nick showed how he could quickly pull related orders information into the display form’s web part page with just a few clicks, and was able to give Karie the information she needed.  Now that the web part page was modified, clicking on any customer in the list brought up not only their company information, but their pending orders as well.

    Key concept:   pull in related data using the “insert related list” action.

    3. New Order form
    (design pattern 1 – connection-oriented)

    New Order Form 

    Once off the phone, Nick put together a page from scratch displaying his customer list, with a list of orders for the currently selected customer, and an order form that was prepopulated with the customer information.  He explained the two connections that allowed him to filter the orders list based on the ID of the selected customer, and to tell the form to populate itself with customer data using a filter on a data connection to the customers list.  (NOTE: filtering and parameterized sharepoint list queries are both now supported in browser forms for SharePoint 2010!).

    Key concept: filter a data connection based on an incoming connection parameter.

    4. Customers master-detail
    (design pattern 1 – connection-oriented)

    Customers List - Master Detail 

    Nick pointed out that the simplest web part mashup to build is a master-detail scenario for a list with a custom InfoPath form.  He threw a list view onto a web part page, added an InfoPath form web part, and simply set up a connection using the “Get Form From” action to specify both the form and the connection to the list in one go.  Now, selecting a customer in the list displays the form for that customer alongside the list, allowing for quick access to data across multiple customers.

    Key Concept: build master-detail pages using the “Get Form From” connection action.

    5. Office Dogfood Voting
    (design pattern 2 – list-oriented)

    Office Build Voting Form 

    This mashup was an alternate implementation of a solution used at Microsoft to track the quality of Office builds.  As people install new builds and use them in their daily work, they can submit votes on whether the build is a good one (thumbs up) or a turkey (thumbs down), with some details.  The mashup page shows a list of builds, with aggregated information about votes cast about that build, and calculated columns which determine a rating for that build based on the number of yea or nay votes.  Nick demonstrated how the form works by submitting the vote to the underlying Votes list and then displaying a “Thank you” view to the user.  He then showed the workflow that increments the “for” and “against” counters for a build based on the submitted vote.

    Key concept: use data in a list to drive workflow and influence the display of other web parts.

    6. Microsoft Helpdesk
    (design pattern 1 – connection-oriented)

    Help Desk Form

    Next, Nick showed a page with two InfoPath forms and a list.  The Helpdesk form is an updated version of the form demonstrated in many of our InfoPath 2007 conference presentations.  It’s a rich form which shows a dynamically determined set of fields and values based on a problem category and problem area chosen by the user in a set of cascading dropdowns.  Based on the chosen category, the form sends a filter parameter, using the new Send Data to Web Part rule action, to filter a list of known solutions related to the problem category.

    A second InfoPath form in the page shows information about the logged-in user.  This display-only web part uses a query against the userprofile web service in SharePoint to bring in information from the User Profile Store.

    Key Concepts:  filtering dropdowns in the browser, using the Send Data To Web Part rule action, creating display-only web parts using InfoPath.

    7. Loan calculator
    (design pattern 1 – connection-oriented)

    Loan Calculator

    This demo showed how to use InfoPath to create a rich form that drives complex calculations in an Excel workbook hosted in Excel Services.  Nick used the Loan Calculator from Office Online, and a simple custom InfoPath form, put them both in a web part page, and then used SharePoint Designer to set up a multiple filter value connection between the form and the workbook.  The form adds default values, data validation, and visual pizzazz to the powerful calculation engine of Excel to create a compelling composite with no code.

    Key concepts:  connecting InfoPath forms with Excel, using SharePoint Designer to specify multi-valued connections.

    8. Insurance claims processing
    (design patterns 1 and 2 – list AND connection oriented)

     Insurance Claims Portal

    Nick showed a 4 part mashup centered around an insurance claims manager looking at claims submitted by customers in the wake of a violent storm.  Clicking on a claim in a list view shows the location of the claim in a custom web part using Bing maps, a photo of the damage in the Image Viewer web part, and an InfoPath form which allows him to assign an adjuster based on the geographic location and set a priority based on the damage photos.  The map shows all of the claims in the list (design pattern 2), but accepts a list item ID as a connection parameter, and centers the map on that pin when a list item is selected (design pattern 1).  Finally, clicking on a pin in the map displays the original form submission in a popup dialog using the showPopupDialog( ) javascript method.

    Key concepts: combine design patterns for complex scenarios, use Bing maps in custom Web parts, display InfoPath forms using showPopupDialog( ).

    9. The Microsoft Giving Campaign
    (design pattern 2 – list-oriented)

    Giving Campaign Web Site

    The final mashup of the day was built around the Microsoft Giving Campaign, which happens this time each year.  Employees are encouraged to donate to their favorite charities, and the donations are tracked to get an overall picture of employee giving.  The Give web mashup shows three web parts, including an InfoPath donation form, a chart web part showing aggregated donations by business division, and a custom Silverlight web part showing progress towards the campaign goal.  (The custom part is a project that Mike Ammerlaan from the SharePoint team demonstrated earlier in the week in his talk on creating web parts using Silverlight.).  This mashup features a similar structure to the Office Build Voting mashup shown earlier, in that there is a single list which contains all employee donations, and a second list which lists donations by business division.  Submitting a donation to the Donations list kicks off a workflow which updates the Divisions list with the new total donation amount.  The chart web part (which ships with SharePoint 2010) shows the breakdown of donations by division, and the Silverlight gauge web part shows a graphical representation of the total number of donations relative to a fixed goal.

    Key concepts: using custom Silverlight web parts, chart web part


  • Microsoft InfoPath 2010

    InfoPath SP1 Released - how to install on systems with InfoPath SP1 Preview


    You can now download and install the official InfoPath SP1.  It is part of the Office 2003 SP1 download.

    More details: .  English SP1 download is here.

    Please pay special attention to the following if you have installed the InfoPath 2003 SP1 Preview:

    InfoPath 2003 SP1 Preview and Office 2003 SP1

    If you previously installed the InfoPath 2003 SP1 Preview, you should uninstall the InfoPath 2003 SP1 Preview prior to installing Office 2003 SP1. You will need your original InfoPath 2003 product CD to upgrade to the final version of InfoPath 2003 SP1. For more information, see the Microsoft Knowledge Base article (873040): Information to consider before you apply Office 2003 Service Pack 1 to a computer that has the InfoPath 2003 Service Pack 1 Preview installed.

  • Microsoft InfoPath 2010

    Executing menu and toolbar commands from the InfoPath Object Model


    While the InfoPath 2003 SP-1 object model is quite extensive, it doesn’t provide all the functionality that is exposed through the InfoPath menus and toolbars. However, you are not limited by that fact. Using the CommandBars object, you can access any of the functionality available in menus and toolbars.

    For example, the InfoPath object model exposes a Print method but not a PrintPreview method.  However, that doesn’t mean that you can’t access this functionality.  Using the CommandBars object, you can execute the Print Preview functionality available on the Standard toolbar like so:

    Application.ActiveWindow.CommandBars(“Standard”).Controls(“Print Preview”).Execute();

    The list of available command bars is on the View | Toolbars menu. If you want to access a menu item, use “Menu Bar” for the command bar name. The control name to use is the same name that appears on a menu or in the tooltip when the mouse is hovered over a toolbar button. (Please refer to MSDN ( for more information about the CommandBars object.)

  • Microsoft InfoPath 2010

    Conditional Presence versus Conditional Visibility


    InfoPath supports a feature called Conditional Formatting which allows among other things to show or hide sections of the form based on some condition.


    However, the underlying XML data still stays there even though it is not visible in the view. What if one wants to remove the XML data altogether? It is easy to achieve this by writing a little bit of code.


    First of all, a trick: an optional leaf field can be wrapped in an Optional Section without adding any additional nodes in the Data Source. Suppose that your data source looks like that:





    Instead of dragging field1 into the view (which will produce a Text Box, assuming its datatype is a string), right-click on it, select More… and pick Optional Section with Controls.


    Now the Text Box is wrapped in an Optional Section and you can remove or insert it as desired.


    At this time, suppose that you want field1 appear conditionally based on a state of a Check Box bound to some node (let’s call it field2). Attach an “OnAfterChange” event to it with the following code:


    function msoxd_my_field2::OnAfterChange(eventObj)


          if (eventObj.IsUndoRedo || eventObj.Operation != "Insert")





          if (eventObj.NewValue == "true")


                XDocument.View.ExecuteAction("xOptional::insert", "field1_1");





                XDocument.View.ExecuteAction("xOptional::remove", "field1_1");




    Here, we use the xOptional::insert command to insert field1 (and hence the Optional Section) when the Check Box is checked, and xOptional::remove to remove it when the Check Box is unchecked.


    A few comments on the code above:

    • The “field1_1” string is the xmlToEdit name associated with the section. To find out what this name is for your section, look at the “Advanced” tab of the Optional Section properties.
    •  When executing actions, InfoPath is using the current XML context to determine how to perform the action. Clicking on the checkbox moves the XML context to field2 in our example. While InfoPath can still handle the insertion properly, it cannot figure out what section to delete. In order for xOptional::remove to succeed, we use SelectNodes() method on the view to set the xml context to the section we are trying to remove.
    • Finally, to prevent the user from inserting or deleting the Optional Section by other means than using the Check Box, bring up the properties of the Optional Section, click “Customize Commands” and uncheck everything under “Insert” and “Remove” actions. Also uncheck the “Show insert button and hint text”.

    P.S. The conditional presence technique is especially useful in scenarios where the schema contains optional elements that are not allowed to be blank (which could be a desirable design in some scenarios where the XML-consuming backend cannot handle xsi:nils).


    P.P.S. The technique of calling View.SelectNodes() can solve the ExecuteAction() focus/context problem. The ExecuteAction() documentation states that sometimes calling ExecuteAction() from button’s onClick can fail. Calling View.SelectNodes() from onClick shold remedy to this problem.

  • Microsoft InfoPath 2010

    Andrew May knows XML Forms on SharePoint

    This is a shout out to Andrew May, who's posted some great content on SharePoint as it relates to InfoPath and XML more generally.
    His most recent post covers the new Form content type that InfoPath uses for its Content Types integration. He's also got a great 5-part series on how the SharePoint XML parser works that InfoPath uses for our property promotion feature. He's even created a poster about how SharePoint parsers work, which you can download, print out, and hang in your bedroom, er, office.
    Another post covers the InfoPath integration with Document Information Panels and Workflows, which shows how important InfoPath dev skills are to the entire Office stack.
    On a completely unrelated note, the recent heat wave seems to have made it to Redmond, where we're in the 90's today. Yowsers!
    - Ned
    Program Manager
  • Microsoft InfoPath 2010

    Encrypting and Decrypting InfoPath Form Data


    This question comes up frequently:

    Can I encrypt the XML data coming out of InfoPath?

    The answer is "yes!", and there is a wonderful article on MSDN that explains just how to do it, titled Extending the Save Functionality in InfoPath 2003. The article covers a lot of ground, and includes managed code samples showing how to perform data encryption during OnSaveRequest and decryption during OnLoad. Similar code can be used during OnSubmitRequest to encrypt the data before sending it out over the wire.

  • Microsoft InfoPath 2010

    Forms Services and multiple IIS Web Applications


    We often get questions asking if the XmlFormView control can be used in a particular environment. Usually you will use it on a regular page that belongs to a WSS Site or on a page in _layouts folder of a WSS site. These scenarios are supported and covered in the following MSDN article on the XmlFormView control at If you want to create an IIS application inside of your WSS site, hosting XmlFormView on the pages of this site is not supported (and actually does not work properly).

    How you can get into this unsupported state

    In Visual Studio, you create New -> ”Web Site” inside http://myWSSserver/_layouts. Then follow the steps to host an XmlFormView control on one of the pages. You add a SubmitToHost handler to the XmlFormView control on your hosting page. When viewing the form, everything seems to be working fine until a post back to the host happens. You either get no results or the “submitted successfully” dialog without your hosted page’s handler called.

    Why it does not work (so you don’t try to use XmlFormView in this way)

    Here are two things that contribute to the issue:

    1. XmlFormView control uses a helper page which is located in the _layouts folder. This page handles AJAX post backs from the control. Every post back that the control makes by itself will be handled by that page. This page can also request that the hosting page performs a full page post back (i.e. for Submit to host). In this case, the Form Services code in the browser will call submit on the page which will then be directed to the original hosting page code for processing.

    2. Forms Services uses the ASP.Net session state to store all of the information about the current document. The ASP.Net session state data is not shared across IIS applications even if the ASP.Net session cookies are the same.

    Let’s combine these two facts with the fact that the “Web Site” that you just create under _layouts is in a different IIS web application than _layouts itself. You have the main page (i.e. _layouts/myWebSite/MyHostingPage.aspx) in one IIS web application but the Forms Services’ post back page (_layouts/postback.aspx) is in a different (default WSS) application.

    From reason 1 above, we can see that most of requests will go to the _layouts/postback.aspx page. Based on reason 2, we will get one Session State data blob for all post backs going to the postback.aspx page (since it goes to the same application). This Session State data blob will contain information about the document you are editing including all changes you are making in the browser.

    When the request needs to go to the hosting page (i.e. when the post back page detects a call to the SubmitToHost handler) then another Session State data blob will be created for these requests (even if they share an ASP.Net session cookie, the request goes to a different application). This new Session State data blob does not have information about the document that was created and edited during the calls to postback.aspx.

    At this point, there are two unrelated Session State data blobs which are holding data about part of your editing session. As you can guess, neither of them contains complete information. Depending on what pieces of editing went to each copy of your Session State data blobs, you can get unexpected behavior after the post back. Often the Forms Services’ code will detect a complete mismatch between the data in the Session State and the information from the browser. It will end up starting a new document to get to a consistent state.

    How to fix it

    Note that the steps below will change your site from living in a separate application to sharing the same application as WSS. Pease make sure that you understand effect of this change (and check if you need a separate application in the first place).

    1. Run IIS Manager (i.e. Start->Run->inetmgr).
    2. In the IIS Manager, chose the web site (in the left pane) where you created the web site in Visual Studio (shown in figure 1).
    3. Right click on the selected web site, choose “Properties”, and on the “Virtual Directory” tab, click the “Remove” button next to “Application name” (shown in figure 3).

    Following image highlights what icon you should see next to supported (green) and unsupported (red) folders:

    Setting on Property page for the folder where hosting of XmlFormView will work properly:

    Here is sample of properties where hosting will be broken. Click Remove button to fix it. Again, note that you need to understand effect of it for your application:

    Alexei Levenkov, Nicholas Lovell, and Balbir Singh
    Software Design Engineers

  • Microsoft InfoPath 2010

    Create a Loan Calculator using the InfoPath and Excel Web Parts


    In this week’s “5 for Forms” video demo, Nick Dallett will show you how to create a loan calculator application without writing a line of code. This simple application leverages the power of the InfoPath and Excel Web Parts by using an InfoPath form to input the values that are sent to an Excel Workbook which contains the complex formulas that calculate the repayments.

    If you want to learn more about the new InfoPath Form Web Part, check out Nick’s earlier video demo – Managing data in your SharePoint Lists using the InfoPath Form Web Part.

    Get Microsoft Silverlight

    Enjoy and please let us know what you think!

    The InfoPath Team

  • Microsoft InfoPath 2010

    Improvements to Share Point integration - Property demotion

    One of the new features in InfoPath 2007 when publishing to a SharePoint 2007 server is the ability to turn on property demotion.
    Property demotion is the ability to be able to modify fields that show up in SharePoint document libraries and cause those fields to be automatically updated in the underlying document (in this case InfoPath form).
    Where would you use demotion?
    Imagine you have a document library where you save your company assets as InfoPath forms. Let us say one of the fields in the library, is the current owner of this asset. When you need to bulk assign a bunch of assets from one person to another, wouldn't it be really easy if you can just update this field in a data grid view instead of opening each and every asset form and having to update it.
    Let us see how you can enable property demotion
    When you go through the publish wizard (File/Publish) pages for publishing to SharePoint, InfoPath will detect if the server is 2007 and if it finds that to be true, you will now be able to turn on property demotion for a field by selecting the check box as shown in the image below.
    Note that not all data types can be demoted and also fields that are within a repeating context cannot be demoted. For data types that don't allow demotion, the checkbox will automatically be disabled.
    Once you enable certain fields for demotion, they become available in SharePoint's data grid view to be edited. The data grid view can be accessed from SharePoint library using the Actions menu as shown below.
    Also since demotion happens on SharePoint side (when the field is edited), the form's business logic such as Data Validation, Rules, Formulas, Code and Script will not run at that time. So there may be situations when you do not want to turn on demotion for certain fields.
    Hope you find this helpful and look forward to see you turning on demotion.
    Lead Software Development Engineer
  • 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.

  • Microsoft InfoPath 2010

    Cool Forms! E-mails to CoolForm@Microsoft not getting through


    It was brought to our attention that external e-mails that were sent to were not getting through. This issue has now been resolved.

    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

    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

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


    Part 5 of 5: The final function


    And the final function is


    function FixupSolutionXSN(








          var XsnInputPath = Combine(inputDirectory, xsnInputName);

          var XsfInputPath = Combine(inputDirectory, "manifest.xsf");

          var XsfOutputPath = Combine(outputDirectory, "manifest.xsf");


          ExtractFilesFromXSN(XsnInputPath, outputDirectory);

          FixupXSF(XsfInputPath, XsfOutputPath, serviceURL, wsdlURL);

          MakeXSNFromFiles(inputDirectory, "manifest.xsf", outputDirectory, xsnOutputName);



    Now the gentle reader has free reins to drive the code above to the helpful utility.


    Converting the script to managed code would be a good exercise as well.



  • Microsoft InfoPath 2010

    Web services are a peach, and then? UDDI!


    I’ve been blogging quite a bit about the brave new world of data connection libraries and UDC files. A data connection library is the recommended way to expose data connections for use in enterprise InfoPath forms. Users can easily select an appropriate connection by name and description without needing to know the connection details – or even the type of connection. Web services, database queries, SharePoint list queries, ASPX pages that return an XML stream – they all look equally friendly.

    Data connection libraries come as a standard library type on the 2007 Microsoft Office Server. But the unfortunate fact is that not everybody has Office Server installed and configured yet. For those of you who need to provide simple discovery of Web service connections in the interim, I’m going to dust off an older, poorly understood, and yet still perfectly functional technology called UDDI. UDDI stands for Universal Description, Discovery and Integration, and it’s a standard way of exposing web service interfaces on a network. For more information on the UDDI standard, check out

    InfoPath allows you to search a UDDI server when setting up a Web service connection. In the pane where you are asked to specify a WSDL file, clicking “search UDDI” brings up the UDDI discovery dialog:

    This UDDI discovery feature was not much used in InfoPath 2003 for several reasons.

    First of all, the default UDDI server listed was a public internet UDDI registry that was co-hosted by Microsoft and IBM. This joint venture was envisioned as a central repository that would become the one place to go on the Internet to discover useful web services. The joint project did not turn out to be successful, so it was terminated earlier this year (see ). However, this does not mean that UDDI is not a viable technology, just that the central Internet registry is not generally useful. UDDI in a more scoped environment such as a corporate intranet is still useful.

    Secondly, UDDI does not allow for filtering results based on the style and encoding of the Web service. Many of the Web services exposed through the Microsoft/IBM registry used the RPC style. InfoPath supports only the document style and the literal encoding, and UDDI did not allow us to filter the displayed list to only those services which InfoPath could support. Exposing UDDI on your intranet allows you to limit the exposed web services to document literal web services designed for use in InfoPath.

    Let me show you how easy it is to set up a UDDI server.

    First off, you need to have a Windows 2003 server set up as an application (web) server. Go into the add/remove programs control panel and choose “add/remove windows components”. In the list, select the check box for UDDI services and follow the wizard to install this component.

    I’m going to assume that you already have one or more Web services deployed. These can be on any server (not just the server on which you’re configuring UDDI). The important thing to have is a URL to the WSDL for each service you plan to register.

    For example, here’s a description of a web service on my personal server. It exposes a number of functions for doing calculations based on my daughter’s current age. Because this is a standard web service, I can get the WSDL for the service by appending ?WSDL to the end of the URL.

    Once UDDI is installed, go to the UDDI home page, and click “Publish” to start editing the registration entries for the server.

    The first thing you want to do is to create a tModel for each service you want to expose. A tModel is a data structure that describes how a service description is exposed. For our purposes, a tModel is simply a pointer to the WSDL file for the service. UDDI Services in Windows Server 2003 makes it easy to create the model, enter the WSDL URL and some descriptive text that will show up in the UI.

    Once you have tModels for your services, you will want to create one or more providers. There’s nothing magic about providers – they are simply names used to provide logical groupings of services. I use a single provider representing my personal website, and all services are exposed under that provider.

    Once you’ve defined the provider, you’ll add one or more services to the provider. For each service, you’ll specify a name, a description, and one or more bindings. The binding is simply an access point for the service. In this case, we’re using the URL to the WSDL file for the service. To specify this, we specify a binding instance, and the binding instance is simply a reference to the tModel we already created.

    Note that the category tab for the service allows you to optionally associate categories with services to provide an additional level of abstraction. Categories are optional and probably unnecessary unless you have a great many services in your registry.

    The final piece of the puzzle is to tie this all back to InfoPath. Empirically, Windows Server 2003 UDDI Services appears to expose UDDI through a web service interface at http://YourServname/YourPublicUDDIPath/inquire.asmx. You’ll want to type this full URL into the UDDI server field. Choose to search either providers or services, and type a search term in the Search For field. I usually type the wildcard operator “%” to search all services. This brings up a list of available services in the Search Results list box. Selecting a service in this box and clicking OK will populate the data connection wizard with the WSDL location for the service, and you’re off and running.

    Nick Dallett
    Program Manager

  • Microsoft InfoPath 2010

    InfoPath and SQL Service Broker


    Rushi Desai, a developer on SQL Server Engine, has posted some blog entries on integrating InfoPath with SQL Server 2005:

    Integrating InfoPath with SQL Server 2005

    Download and try the InfoPathBroker sample

    The first one explains the architecture for interfacing InfoPath with the SQL Server 2005 Service Broker feature. The second has the samples and instructions on how to set up the environment.

    Check 'em out!

  • Microsoft InfoPath 2010

    How to put an image on a InfoPath Button, the KB, and more


    The Microsoft Knowledge Base is an amazing source of content and "How To" type articles, not just a place to go when you think you're seeing a bug.

    Here's one such "How To" article - how to put an image on a Button control:;en-us;832511

    And check out the InfoPath 2003 Support Center:;EN-US;infopath2003

    It features:

    • Highlights & Top Issues
    • Step-by-Step Instructions & How To Articles
    • Links to Downloads, Updates & Utilities

    Also, just a reminder - if you have a question about InfoPath (using it, developing with it, etc) a good to get support is to use the newsgroup microsoft.public.infopath (or try the web interface). The InfoPath team will try and respond to questions posted to the blog comments, but you're more likely to get a quick answer from someone on the product or support team, or another member of the community - like our awesome MVPs - by using the newsgroup.


  • Microsoft InfoPath 2010

    Integrated Innovation: Access Data Collection


    One of the major bets we continue to work on delivering is the notion of integrated innovation.  Across Office, we have applications that are great at certain tasks and one of our jobs is to try and bring those great technologies together to make a fantastic customer experience.  A great demonstrations of this integrated innovation is the Access Data Collection feature. 

    1 + 1 = 3

    Access Data Collection leverages the best parts of Access and InfoPath to help make it super easy to complete the task of gathering data.  As your experience with the product and this blog will tell you, InfoPath is great at adding a rich and familiar Office environment for forms filling.  It provides point of collection data validation and business logic and gives you the ability to have rich and dynamic forms.  But InfoPath is really best suited at collecting data, not reporting it.  Sure InfoPath can merge forms together but often the data analysis needs for the collected data far exceed the relatively simple analysis we are capable of generating with simply merging forms together or generating a flat table in Excel. 

    Obviously, as a database program Access is great at storing and reporting on data.  With its forms there is also a good story for data collection.  However, all users need access to the database in order to use the associated data collection forms.  Here, distributed data collection is an issue. 

    Enter InfoPath e-mail forms.  InfoPath e-mail forms are a great way to collect data from users on the intranet as well as the extranet using the power of InfoPath forms in the context of your Outlook inbox.  We already have a great blog post by Tudor on Using InfoPath e-mail forms that will teach you all about how e-mail forms work and how they can add value to your forms workflow.

    So what happens when you put Access and InfoPath e-mail forms together in a blender and hit puree?  You get Access Data Collection of course.  As with e-mail forms, I get to refer to the great blog posts of others to show you how to make data collection work.  This time pulling from the Data Collection Through Email post by Erik Rucker on the Access team blog.


    When would you use just plain InfoPath e-mail forms over Access Data Collection?  As is always the case, it depends on what you need.  When we built the InfoPath e-mail forms feature, we actively focused on simple data collection scenarios which spanned organizational contacts as well as extra-organizational contacts.  With e-mail forms, the data is returned in your Inbox and can be moved manually or via a rule to a folder where you can see form data in a grid view (see below).

    We also allow you to do some simple reporting on the data by allowing you to export that data to Excel and create pivot tables and charts.  But it is pretty easy to hit the upper bound of what is easily done.  Let’s solidify this and focus on a customer survey (this is especially compelling to me because I have used InfoPath forms to do exactly this).  A very simple customer survey would have a couple different questions, probably without any type of repeating structure.  This is every easy to report in Excel because the data isn’t complicated and the analysis is probably fairly straightforward.  With a couple clicks you can get a graph or chart of your data (and impress your manager with how quickly it all happened).

    Contrast that with a much more complex survey where there are questions dependent on other questions almost like a wizard.  Here analysis of the data will very likely involve complex queries to see relationships between questions, etc.  This is where the power of Access Data Collection comes into play because of the existing capabilities of the database.  Now you have the full capability of a database to hold that data as well as do data manipulation for reporting purposes.


    We strive to make our features work better together and hope that you will take the opportunity to take Access Data Collection and InfoPath e-mail forms for a test drive.  Focus on the scenario, understand what you need to do with you data, and you will see how we can help make your job easier!

    Nathaniel Stott
    Program Manager

  • Microsoft InfoPath 2010

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



    Part 4 of 5: Repacking the XSN


    For packing algorithm we will use another useful utility from the Cabinet SDK which called “makecab.exe”. It can be found in the same place where extract.exe lives.


    This utility needs some data description file that we will build automatically from the XSF file.


    var MakecabExeLocation = "%SystemRoot%\\SYSTEM32";

    var MakecabExe = Combine(MakecabExeLocation, "makecab.exe");


    function SaveToFile(data, filePath)


          var Fso = new ActiveXObject ("Scripting.FileSystemObject");

          Fso.CreateTextFile(filePath, true);

          var TextStream = Fso.OpenTextFile (filePath, 2);





    function MakeXSNFromFiles(






          var DDF = "";

          DDF += ".Set DiskDirectoryTemplate=\r\n";

          DDF += ".Set CabinetNameTemplate='"

                + Combine(outDir, xsnName) + "'\r\n";


          var Dom = new ActiveXObject("msxml2.domdocument.5.0");


          Dom.validateOnParse=false; // for ignoring xsi:nil errors..

          Dom.load(Combine(inputDirectory, xsfName));


                      "xmlns:xsf='" + XsfNamespace + "'");


          DDF += QuoteStr(Combine(inputDirectory, xsfName)) + "\r\n";

          var Filelist = Dom.selectNodes("//xsf:files/xsf:file/@name");

          for (var i=0; i<Filelist.length; i++)

                DDF += QuoteStr(Combine(inputDirectory, Filelist(i).text))

                      + "\r\n";


          var DDFPath = Combine(outputDirectory, "makecab.ddf");

          SaveToFile(DDF, DDFPath);


                + " /v1 /f " + QuoteStr(DDFPath)

                + " /L " + QuoteStr(outputDirectory), true);



    In the last fifth part of the discussion we will come up with the final function.

  • Microsoft InfoPath 2010

    All you wanted to know about browser compatibility


    These articles will help you answer many of the questions you might have about Forms Services browser compatibility, rich-client only features, and the Design Checker.




    Plan browser support (OSS)

    Describes the different levels of browser support for MOSS.


    Creating InfoPath Form Templates That Work With Forms Services

    Describes the following:

    1. Features supported by both InfoPath and Forms Services
    2. Features not supported by Forms Services
    3. Object Model that works in Both InfoPath and Forms Services
    4. Object Model that works only in InfoPath


    Web browser compatibility in InfoPath Forms Services

    Describes the following:

    1. Which browsers are compatible with Forms Services?
    2. Which InfoPath 2007 features are supported in browser-enabled form templates?


    InfoPath 2007 features that are unavailable in InfoPath Forms Services

    Describes the following:

    1. Controls that work in both InfoPath and Forms Services
    2. Controls that work only in InfoPath (lists Design Checker errors and messages)
    3. Features that work in both InfoPath and Forms Services
    4. Features that work only in InfoPath (lists Design Checker errors and messages)


    Microsoft Office server system requirements

    Describes system requirements for all server products, including browser requirements.



    Senior Writer

  • Microsoft InfoPath 2010

    Enabling InfoPath IntelliSense Documentation in VSTA and Visual Studio


    The Microsoft Office InfoPath 2007 setup program installs two .xml files that are designed to display programming information from the Class Library reference inline in the Code Editor and the Object Browser when working with members of the Microsoft.Office.InfoPath and Microsoft.Office.Interop.InfoPath.SemiTrust namespaces.

    Displaying Programming Information in the Code Editor


    Displaying Programming Information in the Object Browser

    For this programming information to be visible in the Visual Studio Tools for Applications (VSTA) and Visual Studio development environments, you must copy the two .xml files from the InfoPath setup directory into the locations in the Global Assembly Cache (GAC) where each of the InfoPath assemblies are installed. To do that, you use the Command Prompt to copy the files as described in the following steps.

    To copy the IntelliSense documentation files for the Microsoft.Office.InfoPath and Microsoft.Office.Interop.InfoPath.SemiTrust assemblies into the GAC:

    1. Open the Command Prompt.
    2. Execute each of the following commands, pressing Enter after each command:

    cd \Program Files\Microsoft Office\Office12

    copy Microsoft.Office.InfoPath.xml %windir%\Assembly\GAC_MSIL\Microsoft.Office.InfoPath\

    copy Microsoft.Office.Interop.InfoPath.SemiTrust.xml %windir%\Assembly\GAC\Microsoft.Office.Interop.InfoPath.SemiTrust\

    Note   If you are running Windows Vista and using User Account Control, you must right-click the shortcut used to open the Command Prompt, and then click Run as administrator to successfully copy the .xml files into the GAC.

    Mark Roberts
    Programming Writer

  • Microsoft InfoPath 2010

    Information Rights Management: Protecting Forms


    In a recent post, we discussed ways to protect sensitive data in your InfoPath forms. This article will drill down on one of these mechanisms - Information Rights Management, a.k.a. IRM. InfoPath 2007 features the ability to set permissions on both the form template that you’re designing and the forms that are based on it. You can choose to restrict who can read or write your form/form template, as well as whether read permissions include the ability to copy, print, etc. This feature is available in the both the designer and editor by clicking the Permission button on the Standard toolbar:

    Form instance permissions
    When filling out a form, users can set permissions for that particular form. Clicking on the Permissions button in the Standard toolbar will pop up the following dialog:

    The user that created that instance of the form will have full control permissions and can grant read or write permissions to other users. Users that do not have any permissions to that form will not be able to even open it.

    This feature can make InfoPath a great tool for scenarios where some degree of privacy is required, for example, feedback to a manager to peer.

    Form template permissions
    In addition to setting permissions for each individual form that is filled out, InfoPath also provides Permission functionality for the form template. When designing a form template, clicking on the Permissions button will pop up the Permission dialog:

    The ‘Restrict permission to this form template’ checkbox at the top will initially be unchecked – check it to turn on Permissions. You will then be able to select users or groups that will have different levels of permissions for this form template.

    Keep in mind that this area only allows you to control access to the form template itself, not to the forms that are based upon it. To restrict permissions to the forms based on this form template, you would check the second checkbox, ‘Restrict permission to forms based on this form template’:

    As mentioned for users setting these permissions in the editor, the user that created the instance of the form will always have Full Control permissions for that form instance, but you can get more specific by clicking ‘Change permissions…’. Here you’ll be able to select who will have Read and Change permissions and which additional features will be available to users.

    If you are designing a form for your specific team, you can take advantage of this feature to only give Write rights to members of the team. Everyone else can be given Read rights.

    Managing your credentials
    When working with InfoPath forms or form templates that have restricted permissions, you can select an account to access the content with. For example, if your personal e-mail address does not have permissions to view an expense reporting form, you can set InfoPath to use your work address instead.

    You can access this feature by clicking on Manage Credentials in the File menu:

    Thanks all. I hope you find this useful.

    One thing to keep in mind is that IRM is not a security feature – there are ways to get around it. It’s there to make it more difficult for users to accidentally or maliciously tamper with sensitive data.

    Program Manager

  • Microsoft InfoPath 2010

    Check if form is new using roles, not code

    Ever want to add conditional formatting or special rules that only fire if your form was just created?
    For example, you want to show one view by default when someone creates a new expense report, but you want show a summary view for everyone else who opens the form.
    Here's how.
    Click on Tools, then User Roles, and use the dialog to add two roles:
    • New Form: Check the checkbox for "initiator" (don’t set any other properties) This role will apply for new forms only.
    • Old Form: Set this one as the "default" in this list
    You'll get something like this in the dialog:
    Now you've got roles to detect whether the user just created the form or is opening it later on, so you can use that information in Rules, Data Validation, Conditional Formatting, even Filters. Just go to the place you want to be conditional, then pick User's Current Role in the first dropdown of the condition, and pick the role you want to test for in the third dropdown (New Form or Old Form).
    You'll get something like this:
    Now when someone opens the form, you'll know if they just created it or are coming back later, and can make your form dynamic accordingly. It doesn't make sense for most forms, but like all the tricks in the blog, I hope this trick helps you make quick progress when the need arises.
    And there you have it. A little tip for the week.
    - Ned
  • Microsoft InfoPath 2010

    Maintain the current selection when moving a node


    In a previous blog entry we showed how to add buttons to move rows in a Repeating Table up and down. We were playing with that solution again and realized it was hard to visually track the items as they moved – each row looks similar so after a click to move the row your eyes have to scan the view to find it again. This is especially problematic if you're trying to move the row several slots up or down.

    Fortunately, there's an easy tweak you can make that takes advantage of the View OM.

    Most operations in InfoPath are data-centric – you cause changes in the view by manipulating the data, which causes a view update. The XDocument.View object provides some view-centric functionality:

    • EnableAutoUpdate/DisableAutoUpdate/ForceUpdate
    • ExecuteAction
    • Export
    • GetContextNodes
    • GetSelectedNodes
    • SelectNodes
    • SelectText
    • SwitchView

    Another blog entry discussed the usage of SelectText and SelectNodes for driving selection within the view. In this case, we'll take advantage of SelectNodes to provide visual feedback to the user when a row is moved.

    In the Move Up/Move Down example, there were blocks of code responsible for moving the XML node corresponding to the row by manipulating the DOM. In the Move Up case it looked like this:

    oParent.removeChild oItem
    oParent.insertBefore oItem, oPrevious

    Simply add this line following those (within the same if block):

    XDocument.View.SelectNodes oItem

    Make a similar change in the MoveDown case. After you've made these changes, Preview, and you should see that when a row is moved it becomes selected. Now it's easier to tell which row was moved.

  • Microsoft InfoPath 2010

    Auto height for sections

    InfoPath forms are all about being dynamic, so it's important that the sections in your form grow and shrink appropriately. For example, if someone deletes an optional section from inside another section, the outer section should shrink accordingly.
    Of course, sections will grow/shrink by default after you insert them, but InfoPath will change it to a fixed size if you resize the section, since we don't want to disobey your command to be a specific size. So in the example above, the outer section will stay the same size even when the Notes section isn't there -- it will just have a bunch of white space in its place.
    The trick: Use "auto"
    If you resized a section by accident and want to return it to the default, just open its properties, switch to the "Size" tab, and type auto for the height. Now it will only be as big as it needs to be and never bigger.
    - Ned
  • Microsoft InfoPath 2010

    Estimate performance and capacity requirements for InfoPath Forms Services environments


    A new document went live today on Technet around capacity planning for IPFS.  Have a look and let us know what you think:




Page 8 of 12 (298 items) «678910»