Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    XPath Powers: Calculating Totals


    InfoPath makes it trivial to track totals for repeating structures, such as customer orders. Just create a repeating table of line items, and sum up the totals for individual line items. However, sometimes, totals for line items may not be available; it is still possible to perform dynamic calculations across the repeating structure, even when interim results (line item totals) are not stored in the data source. This article will explain a way to make this work without code.

    Let's explore the simple case first.

     Form at Runtime Data Source

    Line item total is set by using a default value (price * quantity) on the lineItemTotal node. Creating an order total is just a matter of adding an expression box that uses the built-in SUM function:


    And voila, we're done, totals will be calculated correctly.

    The reason why we are here: the complex case.

    What if the interim results (line item totals in our scenario) cannot be persisted in the data source? This situation might arise if you're operating on a fixed schema, or if you're an "XML purist" (I know I am :-)), arguing that there is unnecessary redundancy in your XML if you store calculated values.

    The goal is still the same - but the data source is different.

     Form at Runtime Data Source

    The line item total would be an expression box instead of the text box; it would be calculated simply as (price * quantity).

    But how do we calculate the order total? Your first instinct may suggest to use sum (price * quantity), but you'll soon discover that the SUM XPath function only takes a nodeset...

    Let's recall the clever technique of iterating through repeating items by using just XPath: it was described in detail in this article. Let's use the following value for the order total expression box:

    sum(xdMath:Eval(my:lineItems, "my:price * my:quantity"))

    Why does this work? Let's go inside-out:

    1) The eval function evaluates the price * quantity expression in the context of line items, and returns a nodeset with the results.
    2) The sum function takes in a nodeset as a parameter, and sums up its contents, giving us the desired total.

    I'm attaching a sample form template that has this technique implemented; save the XSN locally before opening it up.

    This method works in InfoPath 2003, 2007, and is supported in browser-enabled form templates.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    New Office Online and MSDN Resources


    Take a look new InfoPath-related resources that were recently published to MSDN and Office Online:

    1) The official "What's new in InfoPath 2007" review - excellent way to get to know new stuff that's coming with Office 2007.

    2) A series of video walkthroughs on InfoPath 2007:

    3) InfoPath Glossary - InfoPath comes with quite a few special terms; clarify any ambuguities with this tool.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Debugging Browser Forms: Determine the right w3wp.exe


    Last week, we posted an article on techniques around debugging browser forms. We received a few questions around the recommended way to find the right w3wp.exe process to attach to - this article aims to help.

    Non-production Server (where you can do anything without users complaining about service availability)

    It is good idea to use Visual Studio to debug W3WP.exe. It is easier than using WinDbg but way more heavy weight to install. In any case make sure you have proper symbols servers configured properly or have PDB files for your code handy.

    • The easiest approach is to attach to all worker processes at the same time. Both Visual Studio and WinDbg support this.
      To do so, go to "Attach to process" (available in "Tools" menu for VS, "File" menu for WinDbg) and attach to all W3WP processes. Breaking into debugger (on breakpoint or exception) will affect all sites. Users likely to get timeouts or other forms of "service unavailable" responses; make sure noone loses their data while you are debugging.
    • Run IISreset and then execute single request to site you want to debug. It is very likely that there will be only one W3WP started at this point.

    Options for production servers apply to non-production servers, too, but not vice versa :-).

    Production Server

    You are likely will be limited to grabbing stack trace/full memory dump at the moment of exception using WinDbg. You still need process ID; here are 2 way to get it without hurting the server.

    1) Use %windir%\system32\iisapp.vbs to get process IDs of W3WP processes. Note that it might be not trivial to figure out what W3WP to attach to if AppPool is configured as Web Garden or non-default option (new App Pool with port as part of app pool name) was chosen when Web Application was created.

    2) Look into WSS logs (...\web server extensions\12\logs\) for recent entry related to W3WP. Even better, just look for failure trace in the log file and second column is process ID to debug. Note that it could be good idea to bump logging level to Verbose to some or all categories related for Forms Server on "Central Administration" -> "Operations" -> "Diagnostic Logging" page.

    Alexei Levenkov
    Software Design Engineer

  • Microsoft InfoPath 2010

    The xsi:nil attribute


    Have you ever tried to programmatically set a value on a field only to get a “schema validation” error? Many times, this error is caused by the “nillable” attribute being present on the node. The nillable attribute is a special attribute that can appear on an xsd:element within an XML schema. If an element has the xsi:nil attribute specified, it indicates that the element is present but has no value, and therefore no content is associated with it.

    However, if you attempt to programmatically set a value on this node and the nillable attribute is present, you will get an error similar to: “Schema validation found non-data type errors.” You will find the nillable attribute is typically present on the following data types:

    • Whole Number (integer)
    • Decimal (double)
    • Date (date)
    • Time (time)
    • Date and Time (dateTime)

    To resolve this error, your code will simply need to test if the nil attribute is present and if so, remove that attribute before setting the value on the node. The following sample procedure takes an XpathNavigator object, checks that node for the nil attribute and if it exists deletes the attribute:

    public void DeleteNil(XPathNavigator node)


    if (node.MoveToAttribute("nil", ""))



    The above procedure is generic - you can easily call this procedure as needed before programmatically trying to set the value of a field. As an example, this code is called from the click event of a button:

    //Create a Navigator object for the main data source

    XPathNavigator xn = this.MainDataSource.CreateNavigator();


    //Create a navigator object for the field (node)

    //where we want to set the current date value

    XPathNavigator xnfield1 = xn.SelectSingleNode("/my:myFields/my:field1", this.NamespaceManager);


    //Check if the "nil" attribute exists on this node



    //Create a new dateTime object for the current date

    DateTime curDate = new DateTime(DateTime.Today.Year, DateTime.Today.Month, DateTime.Today.Day);


    //Set the value of field1 to the current date in the

    //correct format: yyyy-mm-dd


    Scott Heim
    Support Engineer

  • Microsoft InfoPath 2010

    Conditional Default Values


    Sometimes you want the default value of a field to be dependent upon a condition. However, there isn’t any direct functionality to support IF statements in the default values of fields. Substituting a rule for a default value only gets you so far, as the rule is only applied when that field that changes, not the fields that the rule depends on. Updating the field whenever any dependent field is changed would require you to copy the rule to each field.  This is not very maintainable, so below I will describe two approaches to avoiding this.

    The first approach is simple, but it has some limitations and caveats.  The second approach is more complicated, but should work in all cases. 

    Method 1: Using the union and array indexer operators

    The first approach is to use the union operator ‘|’ along with an array indexer ‘[]’ to select the proper value.  For example,

    if (BoolCondition) {
    } else {


    (TrueResult | ElseResult) [(BoolCondition) + 1]

    You can see that (TrueResult | ElseResult) creates a node set, while [(BoolCondition) + 1] selects which node to choose.  BoolCondition will evaluate to 0 or 1 (depending on its truth value).  Then 1 is added because the node set is 1-based, not 0-based. 

    As a simple example, say that you want to set field3 to field2 if field2 is 10 greater than field1; otherwise set field3 to field1.  On field3’s default value, the expression would be

    (../my:field1 | ../my:field2)[( ../my:field2 > ../my:field1 + 10) + 1]


    There are two caveats to using this approach:

    1) The node set will always be returned in document order. It does not matter what the order is in the parenthesis, as (field1 | field2) == (field2 | field1). Since you cannot change the node set ordering, you may have to modify your BoolCondition to be NOT-ed. For more information on document order, you can visit the page on XPaths.
    2) Inside of the parenthesis, you must only have nodes; you cannot have strings or any other type. So (field1 | “hello world”) will not work.

    Method 2: Using concat, substring and string-length

    To overcome these caveats, you can use the second approach here.  That is to use concat, substring and string-length.  For example, the same generic if statement from the previous approach converts to


    substring(TrueResult, 1, (BoolCondition) * string-length(TrueResult)),

    substring(ElseResult, 1, (not(BoolCondition)) * string-length(ElseResult)))

    The key here is that BoolCondition will evaluate to 0 or 1.  Therefore, the first substring will either take no characters (if BoolCondition is false), or it will take all of the characters (if it is true) of the TrueResult.  Conversely, the second substring is evaluated with the “not” condition.  Therefore, either the TrueResult or the ElseResult will be returned in their entirety, but not both. 

    Let’s say that we want to use the same example as the first approach above,


    substring(../my:field2, 1, (../my:field2 > ../my:field1 + 10) * string-length(../my:field2)),

    substring(../my:field1, 1, (not(../my:field2 > ../my:field1 + 10)) * string-length(../my:field1)))

    The major advantage to this approach is that you can use strings, numbers or anything else as the TrueResult and ElseResult.  For example, we could have placed “Success” and “Undefined” instead of ../my:field1 and ../my:field2. 

    That is all you need to create conditional statements in your default values! I'm attaching a sample form template that has this technique implemented (save the XSN locally before opening it). This method works on InfoPath 2003, 2007, and in browser-enabled form templates. 

    Thanks to Alexei Levenkov and Gary Hsu for their assistance on this article. 

    Nicholas Lovell
    Software Design Engineer

  • Microsoft InfoPath 2010

    Debugging Browser Forms


    Debugging InfoPath forms in the client environment is relatively simple: set a breakpoint, press F5 and execute the process that will cause the breakpoint to be hit. However, debugging InfoPath forms that are opened in the browser requires some additional steps:

    1) Ensure the InfoPath Form Template is compiled in the Debug Configuration so the XSN includes the symbol (PDB) file
    2) Open the local copy of the code file in Visual Studio and set a breakpoint
    3) Attach to the appropriate w3wp process
    4) Execute the process that will cause the breakpoint to be hit

    So let’s take a look at each step individually.

    Step 1: Ensure the InfoPath Form Template is compiled in the Debug Configuration so the XSN includes the symbol (PDB) file

    1) Open the InfoPath Form Template in Design View
    2) Open the Code Editor
    3) From the Project menu choose “<ProjectName> Properties”
    4) Insure the Configuration option is set to Active (Debug)

    NOTE: If you do not see the Configuration option make sure the “Show Advanced Build Configurations” option is enabled: Tools | Options | Projects and Solutions | General

    5) Build and save the project
    6) Publish the Form Template to your Microsoft Office SharePoint Server

    NOTE: If you want to make sure the XSN you are publishing includes the symbol (pdb) file, save the XSN as Source Files and review the resulting files to make sure there is the .pdb file.

    Step 2: Open the local copy of the code file in Visual Studio

    1) Launch Visual Studio 2005
    2) Open the code file (i.e. FormCode.cs) from the project files folder for your Form Template
    3) Set a breakpoint

    Step 3: Attach to the appropriate w3wp process

    1) Open Internet Explorer and navigate to your site
    2) From the Debug menu in Visual Studio choose “Attach to Process…”
    3) For the “Attach To” option make sure this has at least “Managed code” – if not, click the Select button to enable Managed Code
    4) Select the correct w3wp process and click Attach

    NOTE: Determining the correct w3wp process can be a bit tricky. To isolate the correct process:
    - From the server machine, open a command prompt
    - Navigate to the System32 directory and run the following script: iisapp.vbs. This script will list all the currently running w3wp.exe processes, listing their PID and associated application pool id. The application pool id is the only relation between the pid and your application.
    - Use the PID to identify the correct w3wp.exe on the “Attach to Process” screen.

    Step 4: Execute the process that will cause the breakpoint to be hit

    1) Open your form in the browser and execute the process that will cause the code to run – execution should stop when it hits your breakpoint!

    Scott Heim
    Support Engineer

  • Microsoft InfoPath 2010

    Workflow user experience in InfoPath


    Microsoft Office SharePoint workflow can be described as a series of tasks implemented with specific business needs to help people manage their project tasks. In Microsoft Office InfoPath 2007, we provide the workflows user experience for InfoPath forms. Additionally, we enable InfoPath business logic to key off workflow properties.

    This article will demonstrate how to enable an InfoPath form to respond to workflow status. Let's explore the following scenario: Nicholas has created an expense report form template and has associated it with a form library with the “Approval” workflow defined. He wants a form to be displayed at different view when the workflow for that form is approved.

    Step 1: Create a expense report document library by publishing a form template

    • Launch Office InfoPath 2007.
    • Create your expense report form template with two views. For example, one is the expense detail view and one is the summary view.
    • Click the File menu | Save to save your template.
    • Publish your form template to a new document library on a SharePoint site. Name the library ‘Expense Report’.

    Note: please leave the form template open as we will come back to customize this template more in later sections.

    Step 2: Switch to SharePoint and add an Approval workflow to the expense report library

    • Navigate to the SharePoint site.
    Note: you will see Expense Report library created on the SharePoint site.
    • Open the Expense Report library.
    • Add an Approval workflow to this Expense Report library via Form Library Settings | Permission and Management | Workflow

    Note: When adding this workflow, you can specify how, when or by whom a workflow to be started and other options regarding how this workflow should work.

    Step 3: Switch back to InfoPath and add a data connection

    This section explains how to add a secondary data connection to query the workflow status of the workflow you added in the previous section. This secondary data connection provides the data that enables business logic in the form to switch views according to the status of the workflow.
    • Switch back to InfoPath. You should still have your expense report form template opened from step 1.
    • Add a Data Connection that receives data from Expense Report library via Tools | Data Connection | receive data from SharePoint library or list.
    • On the page of Select fields, select the check box next to the name of the field that matches the workflow name.
    • Click Include data for the active form only, and then click Next.
    Note: this step is the key point to retrieve current form’s workflow status.

    • Follow all the default options to finish the Data Connection Wizard.

    Step 4: Add a Rule to the form template to switch to a specific view according to current form’s workflow status

    For this example, we want to add business logic to the form that it will switch to summary view when this form’s workflow is approved. This can be achieved by applying an on load Rule to switch view when current form’s workflow status is equal to “Approved” status.

    • Set on load Rule via Tools | Form Options | Open and Save | Rules
    • When setting Condition, you want to select the workflow status field from the secondary data source you added in the previous section in your first dropdown of the condition builder
    • In the second dropdown, choose "is equal to".
    • In the third dropdown, click Type a number, and then type the value that corresponds to the workflow status.

    Status Numeric value
    In progress 2
    Complete 5
    Canceled 15
    Approved 16
    Rejected 17

    In our example, we choose number 16, corresponding to status "Approved".

    Step 5: Republish the form template

    • Click the File menu | Save to save the changes you made to the template.
    • Click the File menu | Publish.
    • Since you republish the form template, the Publishing Wizard will repopulate previous values. Click Nexts -> Publish -> Close to finish the Publish Wizard.

    Now you have successfully designed a workflow driven expense report form template. When a user fills out an expense form from this library, the view of the form will be displayed according to the status of the workflow.

    Emily Ching
    Software Design Engineer in Test

  • 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 Excellent InfoPath Resource


    Shoutout to - several of our product team alums are hosting an excellent resource for the InfoPath developer community. Lots of great content there: sample form templates, very lively forums, and walkthroughs. My personal favorites:

    1) Localizing form templates. Very clever method, using secondary data connections to store localizations in XML files. I still refer to it as "the Shiraz Cupala method". Note that this method works even better with InfoPath 2007, as button labels can now be dynamic (can come from a data source).

    2) Super-FAQ: auto-generating sequential row numbers.

    3) Interop between rules and code: article on xdextension. Note that this trick is not supported in browser-enabled form templates.

    Alex Weinstein
    Program Manager

  • 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

    Powerful Declarative Logic: Phone Number Parsing


    When entering phone numbers in InfoPath, you can validate that it is a phone number easily enough (Data Validation->field1 “matches pattern” Phone number), but what do you do if the input does not match that pattern? Asking users to exactly enter the format “(000) 000-0000” may be a little constraining. Therefore, you may want a rule so that any combination of spaces, dashes, parenthesis and 10 digits will be reformatted nicely.  Below I will describe how to do this in a rule, although you could do the same in business logic. 

    For the rule’s action, you would want to use translate, substring and concat functions.  Logically, as your first action you would translate to remove all unwanted characters (spaces, dashes and parenthesis).  Then, as your second action substring and concat everything. 

    However, you cannot break it into two actions.  When the translate is executed, it changes the text field.  InfoPath immediately reruns the rule on that field (even before the rest of the actions are run from the first time).  For the second run of this rule, the conditions will all pass (as you would have a number like “0123456789” due to the translate that already happened), and the translate action would be run again.  This will happen repeatedly and causes a recursion error. 

    Therefore, you would need to do this all in one action (the rule will be rerun here, but the conditions will not pass since it will match the phone number pattern).

    On your text box, you will need:

    1. One condition with 3 parts:

    - Field “does not match pattern” phone number “and”

    - Without the “()- “ characters, it has length 10:
    “The expression” string-length(translate(., "()- ", "")) = 10 “and”

    - There are no characters other than digits and “()- “ characters
    “The expression” string-length(translate(translate(., "()- 0123456789", "")) = 0

    2. One action that removes (), - and spaces; takes substrings; and concatenates it all together at once:

    Set a field’s value “.” to concat("(",substring(translate(., "()-", ""), 1, 3), ")", substring(translate(., "()-", ""), 4, 3), "-", substring(translate(., "()-", ""), 7, 4)))

    And you're done! Note that this technique will work in InfoPath 2003 and 2007, and it is supported in browser-enabled form templates. Download the form template that has this trick implemented; make sure to save it to your desktop.

    Nicholas Lovell
    Software Design Engineer
    Alexei Levenkov
    Software Design Engineer

  • Microsoft InfoPath 2010

    Interesting InfoPath/SharePoint Blog


    Shoutout to Kristof De Causemaeker - his blog has interesting articles on both InfoPath and SharePoint; couple particularly cool posts:

    1) Great walkthrough on template parts, new InfoPath 2007 feature that allows you to modularize components of your form templates.

    2) Cool trick on how to make picture buttons in InfoPath 2003 and 2007. It won't work in browser forms, but it can make your smart client forms prettier.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Submitting to 'this' document library


    Have you ever needed to develop an InfoPath form template that submits back to a SharePoint document library but you did not initially know the server or library name when developing the form? Or have a scenario where your InfoPath form template could be published (or added as a content type) to multiple SharePoint document libraries and you need the submit location to be dynamic? Well read on to find out how you can do this!

    When you create an InfoPath form template that needs to be able to submit to a SharePoint document library, you need to specify that connection in the initial design of the form template. However, at run time you can use managed code to determine the server and library name where the form was launched and then modify the “FolderUrl” property of the submit data connection so the form is submitted to the appropriate library.

    So let’s get started setting up this sample. The C# walkthrough below uses the new InfoPath 2007 managed object model; below, you will find attached the same logic implemented in InfoPath 2003 managed object model and in InfoPath 2003 JScript.

    Step 1: Create a sample InfoPath Form Template

    Create a browser-compatible form template as following:

    1. Add 3 text box controls, all with a data type of text, named as follows: strFormURL, strLocation and strFolderName
    2. Add a “Submit” data connection named “Main submit”:
      • Set the document library name to a dummy SharePoint document library (i.e. http://server/dummyLib)
      • Use the concat function to concatenate the strFolderName field and _Test for the File Name property: concat(my:strFolderName, "_Test")
      • Enable the Allow overwrite if file exists property
    3. Set the Security Level of the form to Full Trust and sign the form template with a digital certificate
    4. Enable the Submit functionality (Tools | Submit Options) and choose the “Perform custom action using code” option

    Now that we have the form, controls and submit functionality, let’s add the code to make this process work:


    Step 2: Add the code

    • Click the Edit Code button on the Submit Options dialog
    • Create the following FormState Dictionary object – this will be used to store the form’s location when the form is initially opened:

    private object _strUri
       get { return FormState["_strUri"];
    set { FormState["_strUri"] = value; }


    • Add the following code to the Forms Loading event: 

    // Get the Uri (or SaveLocation in a browser form) of where
    // the form was opened.
    // See if the form was opened in the browser

    Boolean OpenedInBrowser = Application.Environment.IsBrowser; 

    // If so, we will get the "SaveLocation" from the InputParameters

    if (OpenedInBrowser)
    _strUri = e.InputParameters["SaveLocation"].ToString();

       //If it was opened in the client, we will get the Uri
    _strUri = this.Template.Uri.ToString();


    // Populate the fields on the form - keep in mind, this

    // not necessary - this is simply to see the results



    • Add the following procedure to the Forms class: 

    private void PopulateLibInfo(Boolean OpenedInBrowser)


    // Create a Navigator object for the main DOM
    XPathNavigator xnDoc = this.MainDataSource.CreateNavigator();


    // Create Navigator objects for each field

    XPathNavigator xnFormURL = xnDoc.SelectSingleNode("my:myFields/my:strFormURL", this.NamespaceManager);
    XPathNavigator xnLocation = xnDoc.SelectSingleNode("my:myFields/my:strLocation", this.NamespaceManager);

    XPathNavigator xnFolderName = xnDoc.SelectSingleNode("my:myFields/my:strFolderName", this.NamespaceManager);


    // Get the Uri stored in the FormState Dictionary variable

    string strUri = _strUri.ToString();


    // Create a variable to store the path (URL) to the document library

    string strPath = "";

    if (OpenedInBrowser == true) {

       //If we are open in the browser, the strUri value is just

       //the server name and library - so we just need to get

       //the URL without the last "/"

       strPath = strUri.Substring(0, strUri.LastIndexOf("/"));

    } else {

       // Parse just the path to the document library -

       // this would return something like this:

       //  http://server/library

       strPath = strUri.Substring(0, strUri.IndexOf("Forms") - 1);

    // Now, parse the URL to where the document library resides;
    // this would return something like:

    //    http://server or http://server/site
    string strLoc = strPath.Substring(0, strPath.LastIndexOf("/"));

    // Lastly, parse the URL to return just the document library name -

    // in this case,we are looking for the last "/" character

    // knowing that what comes after this is the document library name

    string strFolder = strPath.Substring(strPath.LastIndexOf("/") + 1);


    // Populate the fields on the form – we will use these

    // values in the Submit process





    • Add the following code to the form’s Submit event:

    // Create a Navigator object for the main DOM
    XPathNavigator xnDoc = this.MainDataSource.CreateNavigator();

    // Create Navigator objects for the fields we will

    // use to modify the FolderUrl
    XPathNavigator xnLocation = xnDoc.SelectSingleNode("my:myFields/my:strLocation", this.NamespaceManager);
    XPathNavigator xnFolderName = xnDoc.SelectSingleNode("my:myFields/my:strFolderName", this.NamespaceManager);


    // Get a reference to the submit data connection

    FileSubmitConnection fc = (FileSubmitConnection)this.DataConnections["Main submit"]; 


    // Modify the URL we want to submit to by concatenating the

    // xnLocation and xnFolderName values

    fc.FolderUrl = xnLocation.Value + "/" + xnFolderName.Value;


    // Execute the submit connection




       e.CancelableArgs.Cancel = false;


    catch (Exception ex)


       e.CancelableArgs.Cancel = true;


    • Build and save the project
    • Publish and test

    And that is it! You now have an InfoPath form template that will submit to whatever document library the form was opened from so you do not need to know this information when designing the template.


    Scott Heim

    Support Engineer

  • Microsoft InfoPath 2010

    Data binding between Document Information Panel and Word document

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

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

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

    Two more cool InfoPath/SharePoint blogs


    I found two more cool InfoPath resources.

    Shoutout to Christopher White, who has a couple code-intensive InfoPath-SharePoint articles in his blog. Particularly interesting:

    1) Walkthrough on setting up a pretty complex workflow using InfoPath and Office Server 2007.

    2) Post on manipulating file attachments in С#.

    Kudos to S.Y.M. Wong-A-Ton, who wrote a number of walkthroughs, mainly for the InfoPath client. Highlight: article on using custom XSLT with secondary data sources.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Relinking forms and form templates


    We often see issues when people move forms and templates from one location to another. In fact, the linked nature of InfoPath forms and templates is probably one of the hardest aspects of InfoPath to understand. While the complexities can sometimes seem burdensome, the truth is that the overall model is actually quite simple. Once understood, all it takes is a few small tricks and you will find that moving forms and templates isn’t really that difficult. Moveover, you will have a much better understanding of how InfoPath works.

    The Basics

    InfoPath works by associating a form instance with a form template. The way we do this is typically through a URL association. When you design a form template, it stores the entire description of how the form functions. When published, the form template is put in a location we refer to as the publishUrl (though we expose this in the publish wizard as the access path). Regardless of the name, the key point is that the form template resides in a well known location. 

    Once published, the form template can be used to create new form instances, or just forms. When you create a form against InfoPath, we save the data as straight XML and associate this XML with the form template via a URL. With the URL we know how to associate the form design (layout, business logic, validation, code, etc) with the form.

    The Diagnosis

    As you would expect, things get wonky when the association fails to resolve correctly. This typically manifests itself in one of two ways:
    1) A form won’t seem to update itself when you publish a new version
    2) A form just plain won’t open

    You can usually tell pretty quickly if this is really the issue by creating a new form from the published form template and comparing the processing instructions (PI’s) between the old forms and the newly created form. What you are looking for is this (I have omitted some content for clarity):

    <?mso-infoPathSolution solutionVersion="" productVersion="12.0.0" PIVersion="" href="http://server/site/template.xsn"?>

    If the two form files don’t have the same href attribute in the PI, then you have yourself a linking issue.

    The Remedy

    Once diagnosed, the problem is actually quite easy to fix and can be done in one of several ways. Let’s take a look…

    Hand Edit: The most obvious solution is to simply change the href attribute in the PI to point to the correct form template. You can do this by opening the XML file in your favorite text editor and just correcting the href attribute to point to the correct location. This works great for one or two files but is tedious and mind numbing if you have more than a handful.

    Re-Link: If your form template is in a Windows SharePoint Server form library, then you can use the built in re-link feature to manage the re-linking for you.  Simply move the forms from the old location to the new form library. Once there, you can force a re-link operation. In WSS v2, you can do this by opening the form library, selecting Modify settings and columns, and clicking on the Relink forms to this form library link. In WSS v3, you can access the re-link functionality by selecting the Relink Documents view from the View dropdown. When you perform the re-link, WSS will scan all the XML files for the href in the PI and if it doesn’t match the location for the template associated with the form library, the PI will be updated. 

    PIFix: Finally, if your forms and your form template are living on a file share somewhere, then you can use the PI Fixup tool (pifix.exe) provided in the InfoPath 2003 SDK. This tool will allow you to process any number of input files and change attributes in the form to match your target form template.  Follow the instructions in the SDK or the tool to re-link your form files.


    As with any “under the hood” job, there are caveats.  You will want to make sure you understand what you are doing so you don’t wind up with “extra parts,” as it were.  When changing forms to work against different templates, there are two major things you want to think about before you re-link:
    1) Schema changes
    2) Versioning

    Schema changes are perhaps the most serious issue because they can create data loss if you aren’t careful. By default, InfoPath enforces schema when opening forms against templates.  If the forms XML doesn’t match the schema, we don’t load it. By default, InfoPath works to address this by performing version upgrades on the XML when it doesn’t match the schema. This is great because you don’t need to worry that existing forms will break when you make changes to the form template. However, keep in mind that when elements and attributes don’t match the form template schema, existing data may be deleted to make the form schema compatible. Here is what happens:
    - Add elements/attributes: No worries. If you add elements or attributes to the form template, InfoPath silently adds the element or attribute to the form XML.
    - Delete elements/attributes: Think about it... You deleted the elements and attributes from the form template, so we will remove them from the XML file too. Chances are you didn’t need it anyway (why delete it otherwise?), but you want to pay attention here.
    - Move elements/attributes: Really think about it... When you move an item in the form template’s data source, we treat that as a delete and then an add.  So be aware that data might disappear!
    The bottom line, make sure you understand the schema implications of linking your form to a potentially different form template.

    Versioning issues can cause minor headaches but don’t impact the ability of the form to open nor contribute to possible data loss. The key here is to make sure the solution version attribute in the form’s PI is less than that of the published template. You can find the version number of your form template in the form options dialog as seen below:

    If the form’s version is higher than that of the form template, the you will simply receive a warning message when opening the form telling you that you are opening it against an older template.

    Happy re-linking!!!

    Nathaniel Stott
    Program Manager

  • Microsoft InfoPath 2010

    The anatomy of a UDC file


    OK, we’ve talked about super-fantastic high end authentication scenarios. We’ve talked about cross-domain security and administrative control. We’ve talked about generating UDC files using InfoPath and consuming them again in the designer. Now let’s drill into the structure of the file itself.

    UDC V2 is an XML format, and like any good XML format, there is a schema and a namespace associated with it. I’ll give you the full schema at the end of this post.

    A handy tip: copy the schema into notepad and save it with an xsd extension, then follow the steps outlined in Aaron Stebner’s blog here: to add the xsd file to Visual Studio’s intellisense cache. Once that’s in place, Visual Studio will help you generate your UDC files!

    Basic Structure of the File

    Every UDC file you create will have the structure below, so copy it to notepad and use it as the basis for all your files. This is the infrastructure – the metadata that describes the connection and allows external components such as SharePoint and InfoPath to understand what’s inside.

    <?MicrosoftWindowsSharePointServices ContentTypeID=”0x010100B4CBD48E029A4ad8B62CB0E41868F2B0”?>
    <udc:DataSource MajorVersion="2" MinorVersion="0" xmlns:udc="">
      <udc:Type MajorVersion="2" MinorVersion="0" Type=""/>
      <udc:ConnectionInfo Purpose="" AltDataSource=””/>

    The file begins with a processing instruction specifying a Content Type Id. This is necessary to associate the file with the UDC content type on a Microsoft Office SharePoint 2007 server. Having the content type identified allows the Name, Title, Description, Type, and Purpose fields to be promoted into columns in the data connection library so that the InfoPath designer can see the file.

    By the way: there’s a known issue on Windows Vista where the title property doesn’t get promoted when using the Convert function in the InfoPath designer. To work around this issue, save the file to your local disk, and then re-upload the file to the library using the SharePoint library upload function.

    The root node is called DataSource, and it specifies the UDC version of 2.0, as well as the udc V2 namespace. The Name and Description fields are promoted into SharePoint columns, and they show up in the InfoPath designer when browsing to the file in the data connection wizard. So, while these fields are not strictly required, you should use them to provide useful information about what the data connection is about, and maybe even contact information for the owner of the data source.

    Type (specifically, the Type attribute on the Type element) and Purpose are both required, and very easy to fill once you know the possible values:



    Use for


    SharePoint list query connection


    SharePoint Library submit connection


    Database query connection


    Xml file query connection


    HTTP Post submit connection


    Web service submit or query connection



    Use for


    All query connections


    All submit connections


    Web service only, when both query and submit methods are specified and they reference the same WSDL

    The AltDataSource attribute specifies a second UDC file in the same library. When specified, InfoPath will use the original file, and Forms Services will use the file specified in the attribute. The attribute's value should be the filename of the alternate UDC file. Naturally, the two files should specify equivalent connections - specifically, the connections have to have the same Type and Purpose, and they have to return the same data, or data in the same format.

    The ConnectionInfo Element

    The meat of the connection information is here, and each type of data connection requires specific elements. So, the contents of this element will change depending on the Type and Purpose attributes.

    Let’s run ‘em down, shall we? I’m confident that you can learn by example, so I’m not going to do a lot of explaining here. As I noted in a previous post, we’re working on a schema reference that will fill in the details.

    1. Web Service
    This example is for a query connection. For a submit connection, the Purpose would be WriteOnly, and the ServiceUrl and SoapAction would be contained within an UpdateCommand element rather than SelectCommand.

    Web service is the only connection type that can have both a SelectCommand and an UpdateCommand in the same file. The two operations need to share the same WSDL, and the Purpose in that case is ReadWrite.

    <udc:ConnectionInfo Purpose=”ReadOnly”>

    2. Database
    A database connection is always marked as ReadOnly. InfoPath determines at design time whether submit can be enabled for the connection.

    <udc:ConnectionInfo Purpose=”ReadOnly”>
    Provider=Microsoft.ACE.OLEDB.12.0;User ID=Admin;Data Source=C:\temp\Database1.accdb;Mode=Share Deny None;Jet OLEDB:System database=&quot;&quot;;Jet OLEDB:Registry Path=&quot;&quot;;Jet OLEDB:Database Password=&quot;&quot;;Jet OLEDB:Engine Type=6;Jet OLEDB:Database Locking Mode=1;Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Global Bulk Transactions=1;Jet OLEDB:New Database Password=&quot;&quot;;Jet OLEDB:Create System Database=False;Jet OLEDB:Encrypt Database=False;Jet OLEDB:Don't Copy Locale on Compact=False;Jet OLEDB:Compact Without Replica Repair=False;Jet OLEDB:SFP=False;Jet OLEDB:Support Complex Data=False;
      <udc:Query>SELECT * FROM Table1</udc:Query>

    3. SharePoint list query
    <udc:ConnectionInfo Purpose=”ReadOnly”>

    4. SharePoint library submit
    The FolderName element specifies the default folder name that is used to prepopulate the data connection wizard.  Form designers will still need to specify the file name, as it is stored in the form template.

    <udc:ConnectionInfo Purpose=”WriteOnly”>
      <udc:FolderName AllowOverwrite=”true”>

    5. XML file query
    <udc:ConnectionInfo Purpose=”ReadOnly”>

    6. HTTP Post
    <udc:ConnectionInfo Purpose=”WriteOnly”>


    I’ve described the contents of the Authentication element in previous blog posts, so I won’t go into a detailed explanation. Two things are important here:
    1. The Authentication element must be the last child of ConnectionInfo
    2. If both SSO and UseExplicit are specified, Forms Services will use the credentials specified in the SSO element and will ignore the UseExplicit element.
    This section is used only for forms running in the browser – InfoPath always ignores the authentication element.

     <udc:UseExplicit CredentialType="">
     <udc:SSO AppId="" CredentialType=""/>

    The Universal Data Connection 2.0 schema

    Download the XSD from here.

    - Nick Dallett
    Program Manager

  • Microsoft InfoPath 2010

    Awesome blog on InfoPath


    I've been on a hunt for cool InfoPath-related blogs; well, I just found a gem. Shoutout to Liam Cleary whose blog talks about SharePoint, VSTO, Groove, and, of course, lots and lots of InfoPath. I loved all the screenshots and detailed walkthroughs. Some highlights:

    1) Article on Word import - a walkthrough of a new feature in InfoPath 2007 that allows converting Word documents into InfoPath form templates.

    2) Very interesting article on picking the right technology for your project: Word + VSTO or InfoPath.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Complex Data Validation

    How do you test more than 5 parameters? How do you group parameters? One answer to both questions, is to have multiple validations in one statement. We'll look into these problems in detail in the case studies below.

    Case Study #1

    Problem: a form designer wants to use this logic:

    IF (State="Ohio" or State="Alabama" or State="Arizona" or State="Georgia" or State="Utah" or State="Idaho" or State="Iowa") THEN (fail...)

    Since the Validation UI only supports 5 statements, you run out of room before entering all of the tests.

    Solution: Put more than one test in a statement. If you aren't sure of the syntax, follow along.

    Enter the first three tests.

    Click [OK] to close the dialog. Notice that the syntax is displayed in this dialog:

    Click [Modify] and use this syntax.

    When you change the first column to "The expression", you will see how to refer to the field you are checking. This differs depending on if you are checking the current field or a different field. In this case, State is the selected field, so we can enter the validation like this:

    If you OK this and then come back to it, InfoPath will automatically break out the last 4 tests into separate statements. This makes it easier to see more of the conditions that are being evaluated.


    Case Study #2

    Problem: a form designer wants to use this logic:

    IF (State="Ohio" or State="Alabama") and TaxRate is blank THEN (fail...)

    Using just the default Validation UI, you can't group tests like this.

    Solution:  Put more than one test in a statement. Again, if you aren't certain of the syntax, enter the tests in the Validation dialog:

    Click [OK] to close. Note the syntax in this dialog:

    Click [Modify], and use the syntax shown in the Validation statements.


    Alternative Approach

    Another way to handle both of these scenarios is to use multiple validations:

    This will work and in some cases would be easier to follow (the 50 states could be listed and you could scroll the Validations).

    Performance may be better in one or the other, but that would depend on the logic you are validating.

    All of these statements are evaluated. There is not an implied "and" or "or" combining them. In this last example, if you were checking the "State = ...  OR TaxRate is blank", both would fail. You could check the number of errors and would get 2, even though only 1 error message would be shown (the first one).

    Jerry Thomas
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    Behind the Scenes of Administrator-Approved Form Templates


    If you’re a server administrator for Microsoft Office InfoPath Forms Services 2007, there may be a time when you’re tried to perform some action on a form template and received an error message that looks like the following:

    “Form template was deployed as part of the 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8 feature”

    This feature name probably doesn’t mean a whole lot to you, and the error message could be a bit more actionable, right?  What the heck is this feature thing that the message refers to?  You might also have come across other IDs or other weird timing issues on a multiple server farm.

    Starting the Tour

    So, to shed some light on this, let’s go back-stage to see a little of what’s going on behind the scenes.  The stage is Windows SharePoint Servers Central Administration, where you will find 5 options in the Microsoft Office InfoPath Forms Services group on the Application Management landing page. This tour will mainly be concerned with the Upload Form Template page and a little bit with the Manage Form Templates page. 

    Let’s start at the Upload Form Template page, which is how a form template gets approved by the administrator.  Each new form template uploaded to the farm also adds a new FormTemplate object to the FormsService.FormTemplates which is the singleton FormTemplateCollection object for the farm’s administration object model.  This FormTemplate object allows the same manipulation that is available through the UI.  It also contains a lot of information used only internally to InfoPath Forms Services.  The most important internal property is the converted file, which is essentially a compiled version of the form template that can quickly render as a form template in the browser.

    When InfoPath form templates are uploaded to a server, the Windows SharePoint Services solution deployment and featurization infrastructures are being used to turn the form template into an administrator-approved form template..  Behind the simple click of the Upload button, InfoPath Forms Services creates a feature to deliver the form template (.xsn file).  The feature is then wrapped in a Windows SharePoint Services solutions package which is a .wsp file (just a renamed .cab file) that contains the feature and some other packaging information.

    The Solution Package

    This solution package is the means of deployment to all of the servers in a farm.  All Web front-end servers will have the form template propagated to their file systems, via the solution’s package.  So, there may be a delay in showing up on a multiple-server farm, hence the ellipsis in the “Installing…” status which remains until the form template is deployed to all machines in the farm.  These are propagated via the SPTimerv3 service which runs on each box and is scheduled to pick up jobs from servers running the central administration Web Application (where the Upload took place) and it uses the SPAdmin service to install the solution on the machine, via the administrator account.  So, InfoPath Forms Services deployment needs these services running on each machine, just like WSS solution deployment, because it’s actually the same thing.  Once deployment is completed, the form template is marked with “Ready” status.

    [Side Note: An implementation just like what we use for solution deployment is also available to you.  Our shipping documentation covers how to create features and solutions from scratch.  You might want to do this to bulk deploy many form templates at the same time, to indicated InfoPath form templates in other features or solutions, or to create a custom workflow that contains custom InfoPath form templates.  These custom-created solutions are still registered into the InfoPath Forms Services OM, but will be treated a little differently in IPFS, for instance, you cannot activate/deactivate/remove/upgrade these form templates through IPFS management, because that might invalidate the overall solutions that were constructed.  The whole features must be activated the same way that other custom features are activated (see Ready for Activation, below).]

    Ready For Activation

    The Ready status indicates that the form template can be used and is in normal operation.  The feature created, is a site collection-scoped feature (that’s SPSite-scoped in WSS OM-speak), which can be activated on an site collection like most other site collection-scoped features.  If you are a site collection owner, navigate to Site Settings, and see Site Collection Features under the Site Collection group heading.  Every form template that was administrator-approved through the upload page is available here along with the other site collection scoped features.

    You can also activate and deactivate features from the Manage Form Templates page in Central Administration.  This is exactly the same thing, and is provided as a courtesy for farm administrators who are also site collection owners.

    Behind the Scenes of Activation and Invocation

    An activated form template is added as an item in the Form Templates library at the root site of the site collection (SPSite.rootWeb) in the /formservertemplates path.  The form template is not actually present in the content database for the library, it is stored as a ghosted entry.  A user invoking the form template with the Microsoft Office InfoPath 2007 rich client is actually pulling the form template from the file system of the Web front-end server where it was placed by solution deployment.  Invoking the form template via the browser will pull the converted file from the FormTemplate object in the administration object model.

    The Form Templates library is special in a few ways.  The most important special aspect is that activated form templates cannot be unghosted.  This is to ensure that the converted file version and the on-disk version cannot be different, so that no matter what client you fill the form in, it’s the same form. 

    Be a Better IPFS Admin with this Knowledge

    Our hope is that this article will make our behavior more clear and expose a few tricks to help you be better Administrators.  Here are a few tricks in how to use that information to your advantage.

    Handle the error:  “Form template was deployed as part of the 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8 feature”

    If you receive this, you most likely want to remove the form template and start over.  Here’s the action to take, and it’s only available from the command line:
    "%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE" -o uninstallfeature -filename 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8\feature.xml

    Form template’s status never leaves “Upgrading…” or “Removing…” states

    These states seem to indicate that you're running a multiple-machine server farm, and on your server farm, you're running into some issues in propagating changes to all of the machines.  If you have not done so already, I highly recommend turning on the following services on each machine: SPAdmin, and SPTimerV3 You can do this by running:
                    net start SPTimerV3
                    net start SPAdmin
    On each machine.  Net start is a ensure semantic, so this will not inadvertently toggle or cause any damage if run on a machine where the service is already started.  Now that that's done, you can go on to correcting the problems that you have.

    From Central Administration, go to the Operations page, under the Global configuration group, click on Timer Job Status.  On that page, look for timer jobs that have the name in the following formatting.  If you filename is FOO.xsn, it will look like:
    Windows SharePoint Services Solution Deployment for "form-FOO.wsp"

    See if there was a failure.  If so, go back a page, and go to Timer Job Definitions.  Drill down in the timer job definition that you care about and you can perform the following:

    >> For the case of status stuck on “Uploading”:
    1.       Try to restart the job if that is available.
    2.       If restart is not available, delete the job, then attempt to upgrade again.

    >> For the case of status stuck on "Upgrading":
    1.       Try to restart the job if that is available.
    2.       If restart is not available, delete the job, then attempt to upgrade again.

    >> For the case of status stuck on "Removing":
    1.       Try to restart the job if that is available.
    2.       Else, Remove the job. (continue to step 3)
    3.       Then, go back to the Manage Form Templates and try again to Remove the form template.

    Ed Essey
    Program Manager
    Alexei Levenkov
    Software Design Engineer
  • Microsoft InfoPath 2010

    Hosting InfoPath forms in a custom ASPX page


    Many of you saw a detailed MSDN article on embedding an InfoPath XmlFormView control into a custom ASP.NET page. But - there's more to it. I came across an interesting blog post that talks about embedding a browser-based InfoPath form into a webpart. Here's another post of someone who got it to work, with nice screenshots.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    IE7 is here


    Our friends from the Internet Explorer team are celebrating a major milestone - the release of Internet Explorer 7. You all know about the great features it brings to browser users (security, performance, ease of use); you may have seen them first-hand by trying out their Release Candidates.

    You may be wondering - how does this affect InfoPath? From the first look, there shouldn't be much connection, but there is.

    InfoPath ‘s editing surface is built on top of Internet Explorer. This means that most things that you see when you fill out an InfoPath form are, really, just clever HTML elements. Internet Explorer 7 brings improved implementations - thus, InfoPath users will benefit from the IE7 install, too.

    Some specifics:

    • IE7 provides a windowless SELECT control, which brings better performance for InfoPath forms that use the Drop Down List Box, List Box, or Combo Box controls .
    • IE7 offers full type-ahead support for dropdowns: for example, if a dropdown contains {"apple", "banana", "orange"}, then typing "ba" with the focus on the control will take you to "banana". InfoPath inherits this perk.
    • Overall rendering performance is improved
    • Many InfoPath crashes are fixed

    This list is relevant for InfoPath 2007. InfoPath Forms Services will benefit just like any other web app.

    Bottom line: if your organization uses InfoPath, the returns on deployment of Internet Explorer 7 will be even greater! IE7 will be distributed as a public update; if you can't wait (and I personally couldn't - I downloaded the final release of IE7 the minute I found out it was available), get it here.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Aggregation: and many became one...


    In InfoPath 2003, forms were equipped to merge in a simple manner: repeating sections and tables would merge to form one, as would the contents of lists or rich text controls. The remainder of the form was not merged. This functionality proved useful for many scenarios, but there was much more that could be done. Unfortunately, the only way to do it was to write your own merge XSL. So, in InfoPath 2007, we’ve enabled options that allow you to customize a form’s merging behavior.

    Merge settings are now available in most fields’ and controls’ Properties dialogs. For fields, you’ll find Merge Settings under the Rules and Merge tab. For controls, under the Advanced tab. The available options will differ based on the settings that are available for each type of field. Here’s an example of options available for repeating fields and groups:

    Notice that you can select the order of the merged items as well as whether to combine entries based on a matching value.

    Merge settings for rich text fields vary somewhat from the repeating group ones shown above:

    One of the most useful options is being able to prefix each merged item with some value. For example, if you’re merging status reports from different members of your team, you may want to prefix each entry with the name of the person submitting the report. This’ll ensure that you can keep track of who said what. You can even add fancy formatting for your visual pleasure.

    Changes to the OM

    In the new InfoPath OM, you will see some changes with regards to merging: there is now only one merge event, called – surprise, surprise – Merge. In InfoPath 2003, there were two events: OnMergeRequest and OnAfterImport. The new Merge event has taken the place of the old OnMergeRequest event. We have chosen to deprecate OnAfterImport because there’s no real need for it: InfoPath code executes sequentially, so any code that would have been included in the OnAfterImport event can be placed directly after the XmlForm.Merge() call that actually performs the merge.

    Using InfoPath 2007 to set merging on your InfoPath 2003 forms

    Because InfoPath strives to achieve backwards compatibility, any form template you design in the InfoPath 2007 designer can be saved as an InfoPath 2003 form template. This will allow users that don’t have the newer version of InfoPath to fill out your form.

    Even though the ability to specify how your form will merge is a new feature in InfoPath 2007, InfoPath 2003 already had the infrastructure in place to make it work. In fact, if you knew how to write the appropriate XSL stylesheet, you could have created all the specific merge functionality that is now permitted through the UI.

    So, bottom line, all the fancy merging work that you do while designing your form in InfoPath 2007 will be respected when you save your form template as InfoPath 2003 and have users with InfoPath 2003 fill it out.

    - Bojana
    Program Manager

  • Microsoft InfoPath 2010

    Browser Forms with Spell Check

    With InfoPath Forms Services, you can take powerful InfoPath forms, and allow users to fill them out by using a browser. This enables your forms to reach more customers than ever before. Many Office users have been enjoying the convenience of spell check in Word and InfoPath. To enable this valuable feature for browser forms, we recommend pointing your customers to an Internet Explorer extension called ieSpell. It will check the spelling in your document, just like you would expect it to; you even get to store your personal word list or (clever!) point ieSpell to a Microsoft Office dictionary.
    After filling out a form, hit the ieSpell button and it pops up a dialog, similar to the Microsoft Office spell check. If you want to know the meaning of the word, the thesaurus is just a click away.
    Installing the program is quick and easy. Download from here (free for non-commercial use). When you're done, you will see a new button in the IE toolbar, as well as a new Tools menu item.
    If you are interested to learn more about ieSpell and other browser extensions, take a look at this article from the Internet Explorer team blog.
    Pradeep Rasam
    Program Manager
  • Microsoft InfoPath 2010

    Two excellent InfoPath resources


    I just came across two great InfoPath resources:

    1. A series of articles by Christopher Domino (12 detailed articles so far!). Christopher's articles look deeply into many InfoPath aspects, from "declarative logic vs code", deployment approaches, and backend integration discussions to detailed code dive-ins. Highly recommended.
    2. has a few interesting InfoPath articles; I particularly liked their review of the Logic Inspector (new InfoPath 2007 feature that offers an easy way to debug form logic) and the walkthrough on how to invoke BizTalk orchestrations using InfoPath.

    Alex Weinstein
    Program Manager

Page 6 of 12 (298 items) «45678»