Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    Cool video on InfoPath in Outlook

    As part of getting everyone up to speed on Office 2007, and in preparation for the imminent release of the Beta, we've just posted some "Partner technical readiness training" videos.
    It includes a great one on using InfoPath in Outlook, so I thought I'd call it out:
    You can check out all the videos here:
  • Microsoft InfoPath 2010

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


    Part 2 of 5: Unpacking the XSN

    To unpack XSN one should use extract.exe utility. It can be found in the %SystemRoot%\system32 directory or in the Microsoft Cabinet Software Development Kit. For the command usage details just run “extract /?”.

    In this part we will also introduce several auxiliary functions that will be extensively used throughout the entire discussion topic.

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

    var ExtractExe = Combine(ExtractExeLocation, "extract.exe");


    function Combine(dir, file)


          return dir + "\\" + file ;



    function QuoteStr(string)


          return ("\"" + string + "\"");



    function Exec(string, flagWait)


          if (flagWait == null)

                flagWait = true;

          var WScriptShell = WScript.CreateObject("WScript.Shell");

          return WScriptShell.Run(string, 0, flagWait);



    function ExtractFilesFromXSN(xsnInputPath, outputDirectory)


          var Parameters;


          // add the location to place extracted files,

          // a flag "/Y" that prevents prompting before overwriting

          // an existing file, and a flag "/E" that orders to

          // extract all files

          if (outputDirectory != null)

                Parameters = " /Y /E /L " + QuoteStr(outputDirectory);



                + Parameters

                + " " + QuoteStr(xsnInputPath), true);


    Now we have a tool to unpack XSN. All of the InfoPath form template files are accessible for changing. In the next part of the series we will be modifying the manifest itself.

  • 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

    SQL Server 2005, Part III: Magic of Structured Search


    You were patient enough to read through my ramblings about why Yukon and InfoPath are a match made in heaven, and how to set up basic interop. But these two articles left you dreaming of more. Well, that was their purpose :-).

    Magic begins: Structure-aware query. Full text search is, ahem, much less powerful.

    Just imagine: you built your resume system. HR folks can search the records by the first and last name of the candidate. Useful, but far from magical. HR comes to you and says: "hey, we want to search by years of experience!"; next day, the way to search by job title, then, they want to see candidates with EA experience...

    Query parameters keep coming every week. You're getting sick of modifying the system; maintenance costs are growing. Programming the system is no longer fun.

    Well, that was yesterday.

    Today, with Yukon, you can build dynamic queries for your customers on the fly: this involves writing an XPath expression or two. In the next few steps, we'll assume that you have the basic setup completed (if not yet, follow this article).


    Start with the goal

    Here's what we're trying to build:

    Works like this: pick the property you want to search (the list is dynamic); select a value that you want to search that property for; then click Run Query. This performs a few calculations, then calls a web service, and shows the result set. Then, the user can drill down on each record using the Details button.

    Why? Where's the magic? HR comes and says "I want another query criteria", and you deliver it by authoring one line of XPath in an InfoPath form. No form template modifications, no web service modifications, no C# to write.

    Here's what the end goal looks like at design time:

    Going through the building blocks:

    1) fieldToSearch dropdown: this is the core of the magic. Here you specify key-value pairs for "what XPath you want searched vs the name of the search". For example, the Job Title search option that you see on the screenshot above maps to a smart-y XPath 


    You can conceptually see that the JobTitle node will be searched for values specified somewhere. Hey, you might ask, where's that printf() syntax coming from?? You'll see an answer soon - we'll be doing a substitution of %1 for a real value coming from the fieldValue node in the web service code, described in detail below.

    The key-value pairs for this dropdown would likely come from a secondary data source - an XML file that you'd keep separately, and author using another InfoPath form. Here are some sample values:

    Display Name of
    the field to query
    Search XPath (value)
    Name //ns:Name[//ns:Name.First = "%1" or //ns:Name.Last = "%1"]
    Job Title //ns:Emp.JobTitle[contains(.,"%1")]
    Job State //ns:Location[ns:Loc.State = "%1"]

    2) fieldValue textbox: this allows the user to specify the value to search for. In the example above, they said that they want to search the "Title" field for the word "Manager".

    3) Run Query button: has a rule on it, with a few actions - using the Logic Inspector:

    Here we're setting the parameters on the secondary data connection that queries a web service; here's a screenshot of its data source:

    Why are we hard-coding the select XPath? Just for this example, it's likely that the basic info would be "show me the first and last names, and if I want to drill down, I will". Everything else is dynamic; if you'd like, you can specify selectXPath dynamically in the separate XML file mentioned in step 1.

    Now the web service method source code - the beauty is that it's completely generic, and you don't have to change anything in the web service

    /* criteriaXPath must contain %1. It will be used to substitute in the criteriaValue
    * selectXPath must point to one, and only one text node (concat's are fine -
    *          just make sure that result can be casted to varchar)
    * None of the parameters should have a single quote in them: this is just a ,
    *          you may want to improve this before going to production (escaping).
    public XmlDataDocument DoXQuery(string criteriaXPath, string criteriaValue, string selectXPath)
        XmlDataDocument result = null;
        string criteria = criteriaXPath.Replace("%1", criteriaValue);

        using (SqlConnection conn = new SqlConnection(connString))
            string command = @"
                WITH XMLNAMESPACES (
                    '' AS ns

                    JobCandidateID AS id,
    + selectXPath + @"',  'nvarchar(128)') AS value
                FROM "
    + tableName + @"
                WHERE Resume.exist('"
    + criteria + "') = 1";
            SqlDataAdapter myCommand = new SqlDataAdapter(command, conn);
            DataSet ds = new DataSet();
            myCommand.Fill(ds, "JobCandidates");
            result = new XmlDataDocument(ds);
        return result;


    And you're done!

    Alex Weinstein
    Program Manager

  • 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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    InfoPath 2010 Performance Highlights


    At last week's SharePoint conference in Las Vegas, Rick Severson, a test lead on the InfoPath product team presented a session called Performance Best Practices for SharePoint Forms Services 2010. This session covered best practices and performance improvements in InfoPath 2010. In this post, we will cover the highlights from this session.

    InfoPath Team Members who attended SPC:

    (From Back Row Left to Right: Daniel Witriol (Program Manager Lead), Darvish Shadravan (Technology Specialist), Rick Severson (Test Lead), Nick Dallett (Program  Manager Lead), Roberto Taboada (Program Manager), Bojana Duke (Program Manager), Peter Allenspach (Group Program Manager), Umut Alev (Development Lead))

    SPC - InfoPath Team Picture

    We had about 100 people in the room for this deep dive of InfoPath performance best practices. Rick opened the session by defining what fast forms are. He used a sample 1040EZ form to demonstrate a "lightning fast form" out of the box. In InfoPath Forms Services 2010, we've improved performance by achieving initial form load times of .8 seconds and subsequent form loads of .4 seconds. A sample passport form with 60 controls and some simple rules and data validation was used to demonstrate that requests per second (RPS) have increased. With this form, 1200 requests can be processed per second. That's a total of 2.1 million users per hour.

    Rick then moved on to cover some of the scalability highlights in this release.

    • Requests per second (RPS) have doubled. 
    • We can now scale out to 8 Web front ends for a single backend. 
    • Performance of SharePoint lists that have been customized using InfoPath is comparable to the default, out of the box SharePoint lists.
    • Forms with Sandboxed code can process 340 RPS in a 1x3 topology
    • Our new State Service allows for better scaling and faster session performance
    • We’ve ported many fixes into 2007 SP2 so you can take advantage of many of these performance gains today

    Performance improvements include -

    • Our new, enhanced rich text control which is optimized for multiple instances on a form
    • OnHover rendering of secondary data which improves rendering time
    • Performance in customized SharePoint lists ensures that you get the richness of InfoPath without sacrificing performance
    • New State Service
    • Optimized .js for Ajax behavior rendering

    InfoPath 2010 - Performance Improvements

    In the next part of the session, Rick covered some best practices for optimizing the performance of your forms. He focused on the following 4 areas - Data Connections, Controls, Data size and business logic.

    • For optimal performance, he recommended that you filter data at source rather than returning large data sets when querying data sources. 
    • InfoPath 2010 users can now take advantage of our new browser form filtering capabilities. 
    • Users should avoid running data queries on form load and instead run them on demand.
    • It's a good practice to combine data queries with other actions, such as view switches to minimize the number of postbacks.
    • To further improve performance, we recommend that you reduce form complexity, avoid out of context controls and avoid postbacks.
    • When possible, you should take advantage of first request optimized forms.  You can do this by avoiding logic in your form that has to be calculated on load.  For example, if you use a default value of DateTime.Now(), then this has to be calculated on load so the form cannot be first request optimized. 

    InfoPath 2010 Performance - Areas to tune

    The key takeaways from this session were high performance out of the box, complex solutions can be tuned easily and performance matters!

    Additional Resources for improving the performance of your InfoPath forms:
    Designing Browser enabled forms for Performance in InfoPath Forms Services

    Capacity Planning Document For IPFS

    InfoPath Forms Services 2007 Web Testing Toolkit

  • 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.

Page 8 of 12 (298 items) «678910»