Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    Using SQL Server 2005 Web Services with InfoPath


    Here’s your problem: You want to use a stored procedure in a database to access your data through InfoPath, but you don’t really want to have to write script for every query to change the stored procedure’s query parameters.  We’ve all been there.

    Well, stop your coding, right now, because SQL Server 2005 allows you to create SOAP Web Service “endpoints” that act as a type of exposed stored procedure over HTTP.  Among other cool things, this will allow you to have the parameters you need exposed as query parameters in InfoPath’s data source.  It's easy to set up in SQL Server 2005 using the CREATE ENDPOINT T-SQL statement.  For example, let's say there is a simple Stored Procedure called "getAge" that takes an integer value and returns every person in a table that has that age.  The SQL statement to expose that Stored Procedure as a document literal SOAP Web Service could look like this:

    CREATE ENDPOINT getSpecifiedAgeEndpoint




       SITE = 'myserver',

       PATH = '/getspecifiedagewebservice',


       PORTS = ( CLEAR )




       WEBMETHOD 'GetRecordsWithSpecifiedAge'


          NAME = 'AdventureWorks.dbo.getAge',

          SCHEMA = DEFAULT,



       WSDL = DEFAULT,


       DATABASE = 'AdventureWorks'


    The web service will then be located at http://myserver/getspecifiedagewebservice?wsdl.  Note that this web service will not be exposed through IIS; It’s all happening directly from SQL Server 2005.  One method will be exposed at the URL called “GetRecordsWithSpecifiedAge”.  For more information on getting the endpoint up and running correctly, see this MSDN article.

    Note that a few rules apply to the settings that you put in the CREATE ENDPOINT statement that will make it so your Web Service plays nice with the InfoPath Rich Client.  That is, you are probably better off keeping the FORMAT = ROWSETS_ONLY setting as it appears above.  If not, then your web service will return a good deal more information about the query itself than just the rowset data you want, but it will still work for you.  Additionally, setting BATCHES = DISABLED will disable the sqlbatch webmethod from being automatically available on the web service, a powerful webmethod that you should probably keep disabled if you don’t intend to use it.

    At that point, you should be able to design a form template against the web service like any other.  Using SQL Server 2005 rowsets with browser-enabled form templates is currently not a supported scenario; we’ll keep you posted on possible workarounds.

    Also note that when you are designing a main web service against one of these web services that returns row data, InfoPath will warn you in the Data Connection wizard that the web service may return multiple datasets, and that’s an InfoPath no-no.  Under most circumstances, only one dataset will be returned (a dataset can still have multiple tables) so you can usually safely thank InfoPath for letting you know, and continue on.

    Travis Rhodes
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    Help Us Improve InfoPath: Send Us Your Forms!


    The Microsoft Office InfoPath Team is interested in seeing how you are using InfoPath.  We would like you to send us your InfoPath forms so we can review them and collect data on how you are using the forms.  We will be using these forms to implement improvements in future versions of Microsoft Office InfoPath. We are interested in looking at a variety of forms ranging from simple to complex (in terms of length, rules, data connections, code, etc.).

    Please send us your forms at and include a brief description of how the form is used, what is working well for you and any suggestions for improvement. Also let us know if we can contact you with any follow up questions.

    We cannot guarantee that every form will be reviewed or that the confidentiality of the forms or information contained therein will be maintained.  We ask that you not submit forms containing confidential information.
    Thank you for your submissions.  We look forward to hearing from you.
    Microsoft Office InfoPath Team

  • Microsoft InfoPath 2010

    Do you blog about InfoPath?


    I'd love to compile a list of blogs about InfoPath to help the developer community connect and share insights. If you wrote at least one InfoPath article in the past, and plan on writing more, please leave a link to your blog in the comments.

    Expect an OPML compilation in a week or two!

    UPDATE: OPML compilation is here.


  • Microsoft InfoPath 2010

    Use Rules and Filters to Create Cascading Dropdowns in Forms


    Hi, my name is Anson Hidajat and I’m a program manager on the InfoPath team. In this week's “5 for forms” video demo, I will show how you can use rules and filters to create cascading dropdown lists in a tennis tournament bracket application.

    Get Microsoft Silverlight

    Enjoy and please send us your feedback!

  • Microsoft InfoPath 2010

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


    Part 1 - Introduction

    InfoPath Forms Services (IPFS) is a Web service system integrated with SharePoint that enables you to deliver InfoPath forms on the Web through a browser. These browser-enabled forms extend the reach of your forms system, since your users do not require the InfoPath rich client to display and fill out the forms. When you are designing browser-enabled forms, optimizing performance should be an important objective for delivering the best possible form filling experience to your users.
    To help you reach this objective, we are introducing a series of articles about optimizing the performance of InfoPath browser-enabled forms. We will cover design issues and enhancements that can either degrade or improve the performance of your InfoPath forms system. Information in this series will help you gain a better understanding of differences between an InfoPath rich client form and a browser-enabled form, the interaction between the browser and the IPFS server system, what form features cause postbacks, factors affecting the rendering of a form in the browser, how to identify problems and monitor the performance of your forms system, and other tips for improving the performance of browser-enabled forms.

    Who should read this?

    Who should read this series about designing InfoPath browser-enabled forms for improved performance and scalability? First, anyone who is interested in learning more about the design and delivery of  InfoPath forms on the Web. Second, anyone who has to design and support large or complex forms. Third, anyone who needs to support a significant number of concurrent form users and is concerned with the performance and scalability of their Web form system under load. Whether you are an experienced form designer or are new to InfoPath, the information in this series will help you improve your understanding and control of the behavior of your InfoPath browser-enabled forms.

    What do we mean by "performance"?

    When describing the behavior of InfoPath browser-enabled forms on the Web, what do we mean by "performance"? Simply put, "performance" is the subjective perception of how responsive the form feels for the person filling it out in their browser. This perception is influenced by how quickly the form loads and how quickly it reacts to the user's input. Performance is good when your users don't have to wait for a form; it is bad when they do. As a form designer, your primary goal is to manage the overall user experience, and your primary performance goal is to minimize the time your users spend interacting with the forms. At the same time, it is equally important that your server system be able to scale to meet expected demand while maintaining an acceptable level of responsiveness. Of course, these are not your only goals - you must also deliver a form that meets a stringent set of design, business, and technical requirements. 
    Just as good form design requires balancing design and layout with business and technical requirements, good form performance happens as the result of a complex set of factors. Some of these factors might be outside of your direct control as a designer, but they must be considered in your design to achieve your performance goals. Some of these factors include:  the user environment, expected usage patterns, peak loads, network and server architecture, database design, custom code, and interaction with other applications in your SharePoint environment. The more you know about these factors of your form deployment and how they interact with your form design, the more effectively you can manage the issues that affect browser form performance. 
    Generally speaking, some of the most important objective measures for gauging performance are response time, throughput, and resource utilization. These measures can be used on the server to evaluate how efficiently requests are being processed. They can also provide insight about whether an issue is occurring on the server or in the browser. Use these measures to analyze actual performance, develop baselines, and understand the effect of your changes during troubleshooting and tuning activities. Although beyond the scope of this series, as you develop your framework for evaluating forms performance under various conditions, you should plan on developing load, stress, and capacity testing around these measures. The more objective you can become about performance, the more effective you will become at finding and removing performance bottlenecks. Later in this series you will learn more about tools for monitoring the performance your InfoPath forms system.
    Ultimately, because each environment and set of form requirements is unique, there is little prescriptive guidance that is both general and specific enough to be useful. As you optimize rendering performance in the browser, throughput might increase, but certain improvements in throughput might in turn reduce the responsiveness of a form in the browser. Or it might increase resource utilization on the server, reducing the server's ability to scale when subjected to heavy loads. In the end, you must make decisions and tradeoffs to resolve the various elements of form design with respect to the characteristics of your system, and your design, business, and performance goals. Armed with the information presented in this series of articles, you will be better equipped to make decisions that improve the performance of your InfoPath browser-enabled forms.

    Common causes of poor performance

    There are many conditions that can put a drag on the performance of browser-enabled forms in an InfoPath Form Services system. The following list is a sample of some of the most common conditions:

    • Slow network connections
    • This is an important factor in the actual performance of any server system, especially one that uses the Web. It’s something you should keep in mind as you design, test, and deploy any web-enabled form. Although there are many things that affect performance at the network and system level, and that can be done to improve it, these are beyond the scope of this series.

    • Large amount of HTML
    • Large forms that require large amounts of HTML to be transferred and rendered reduce the responsiveness of a browser-enabled form. Rendering performance will be the subject of an article in this series.

    • Large amount of XML
    • Again, large, complex forms can contribute to poor performance of an InfoPath Forms Services form system. Since Forms Services processes form XML on the server, forms with large amounts of complex XML require additional server resources. When there are many concurrent users, the additional stress on the server reduces scalability and throughput, and increases latency. In addition, a large amount of XML can slow form rendering in the browser. In this series we’ll look at a number of issues that make form processing more expensive.

    • Form features that cause postbacks
    • Certain form controls, actions, and features require the browser to communicate with the server during the form-filling session. This exchange of data during the session is called a postback, and it usually occurs when a form feature needs to send data to the server for processing and then has to wait for a response to update and re-render the form. We’ll look at specific features that cause postbacks in our next article.


    What's next?

    The next article in this series will look at some of the differences between InfoPath rich client forms and browser-enabled forms that have implications for performance. The most significant difference involves the postbacks that the browser sends to the server for processing. Whether you are familiar with InfoPath or you are new, you will learn something new and useful about the interaction between the browser and the InfoPath Forms Sevices server system.


  • Microsoft InfoPath 2010

    Where do UDC files come from?

    Where do UDC files come from? - I knew you’d ask. (For those of you who are wondering what a UDC file is, you should go read my post entitled "Making data connections work in browser forms.")
    There are a couple of ways to go about it. UDC files are just xml files with a specific namespace and schema, so once you have a few examples you can probably get around handily with notepad and cut and paste. However, we’ve made it easier than that with the new Convert functionality on the Manage Data Connections dialog. (For those intrepid souls who prefer the notepad route, a schema reference is being prepared for publication.)
    If you start out by designing your data connection the way you normally would, you can then use the Convert button to change the connection from settings in the form template to settings in a data connection file. (In fact, you can open any existing form template in InfoPath 2007 and convert existing data connections the same way.)
    To start with, make sure you have write permissions to a data connection library (henceforth "DCL") on the Microsoft Office SharePoint 2007 server you’re going to publish your form to. Then, using InfoPath 2007 Beta 2 or later, create your data connection or open a form template with an existing data connection. Make sure the connection is to a source supported by UDC. (E-mail connections, connections to a Microsoft Access database, or connections to an XML file in the form template cannot be converted to UDC connections.)
    Here’s the data connections dialog showing a few connections I threw together (you can get to this dialog off of the "tools" menu in InfoPath design mode):
    Click the Convert button and specify the path to your data connection library. If you click "Browse...", InfoPath will suggest a filename based on the name you gave the data connection when it was created.
    If you choose a data connection file that already exists, InfoPath will use the settings in the file you chose - don’t expect it to overwrite the original file with new settings. This could have unexpected results if the file that’s already in the library is a different connection type or returns data that does not conform to the schema your form template expects.
    For most cases, you want to leave the default connection link option. Choosing "centrally managed connection library" will cause InfoPath and Forms Services to look for the UDC file in the "Manage data connection files" library in SharePoint central admin. This is fine, but it means that you need to copy the file from the DCL where you created it to that location before you can use it. This presumes you have access to SharePoint Central Admin. See my last blog post entitled "Making data connections work in browser forms" for more information on this option.
    Once you click "OK" on this dialog, your UDC file will be created and saved to the location you specified, and the connection in the form template will be modified to retrieve settings from the UDC file rather than from the form template.
    NOTE: There’s a known issue in the Beta 2 release where you will see an "invalid URL" dialog at this point. This is benign and is no longer seen in the technical refresh.
    You now have a UDC file in your DCL, but you’re not quite done. By default, a DCL will require content approval before anyone other than the file’s owner can use the UDC file you uploaded. Unless the content approval requirement has been removed, a site administrator or someone else with the content approval right will need to set the file’s status to "approved."
    Adding Authentication
    InfoPath does not automatically configure server-only authentication options for you. However, when creating a UDC file, InfoPath automatically creates an authentication block within the UDC file that is preconfigured to use Office Single Sign-on. In order to use this authentication option, you’ll need to uncomment the authentication block within the file and add both the SSO application ID and the CredentialType. Most of the time, you’ll want to use the SSO credential to log onto Windows, for which you’ll need to specify "NTLM" as the CredentialType. The full list of possible credential types is as follows:
    Credentials will be embedded in a database connection string for authentication against a SQL server.
    Credentials will be used to impersonate a Windows user
    Credentials will be used to impersonate a Windows user using Kerberos
    The username will be used to impersonate a Windows user using Constrained delegation
    Credentials will be used to perform HTTP Basic authentication
    Credentials will be used to perform HTTP Digest authentication
    Reusing existing UDC files
    Once you’ve created your UDC file, you may want to use the same connection for other form templates. Among other things, this has the benefit of sharing settings for multiple forms in a common location. Changing the settings in the UDC file will cause all of the related forms to pick up the changes the next time they are used.
    There are several places in InfoPath where we expose the ability to re-use data connection settings exposed as UDC files in a data connection library. Here are a few examples:
    All of these entry points lead to this dialog:
    When you specify one or more SharePoint sites to search, this dialog allows you to browse available UDC files containing in DCLs on those sites. Based on the context, this dialog is filtered to show only applicable connections (for example, if you start from the "Design a form" dialog, this dialog will only show Web service and database connections).
    Once you’ve specified the UDC file to use, you may need to specify some properties for the connection that are not contained in the file (for example, for a SharePoint list connection, you’ll be asked to specify which columns to include in the data source), but otherwise, you’re done.
    - Nick Dallett
    Program Manager
  • Microsoft InfoPath 2010

    Use Visual Studio to create InfoPath forms… without code

    Although the primary purpose of Visual Studio 2005 Tools for Office (InfoPath 2007 Support) is to add C# and Visual Basic code to your InfoPath form template, you can still take advantage of hosting InfoPath inside Visual Studio to design forms that don't have any code.
    When you create a new InfoPath form template project in Visual Studio, by default, it will be created with code enabled.  To obtain a form without code, you need to explicitly remove the code from the form by using the remove code button in the programming tab of the form options dialog.
    After clicking on this button, you might be confused to see that the code file is still present in the project.  Don’t worry about this.  When you build the project, the hosted designer will not add the output assemblies to the form template.
    How it works
    After a new project is created, the “enabled” attribute of the “managedCode” element in the manifest.xsf defaults to “yes”.  Clicking the remove code button sets this attribute to “no”.
    <xsf2:managedCode … enabled="no"></xsf2:managedCode>
    This attribute is set back to “yes” when you insert an event handler using the hosted InfoPath designer.
    After a success build, the output assemblies will only be included with the form template when this attribute is set to yes.
    - Gary
    Software Development Engineer
  • Microsoft InfoPath 2010

    Don't settle for just one: Adding multiple default rows

    Since I realize not everyone has installed the Beta yet (you can do it!), I figure it's time for a trick everyone can play with, even those still using InfoPath 2003.
    Starting with more than one row in a repeating table
    You may want to do this if you have a form where you know everyone's going to fill out at least five rows, or maybe some people will even print our your form before typing in their answers (I never!). You might even want to have five rows exactly, and then disable adding or deleting rows (in Repeating Table properties), but still use a repeating table to get the data structure you want.
    Regardless of your scenario, here's how to do it:
    1. Open the form in design mode
    2. Click Default Values on the Tools menu
    3. In the data source, select the group that's bound to the row of the repeating table
    4. Click the down arrow next to the group name
    5. Select "Add another row below"
    You can even specify different values for the columns of each row using the bottom of that dialog. And of course this works for any repeating item in your data source, not just those bound to repeating tables.
    Keyboard trick!
    Save yourself a few clicks by typing the "Insert" key instead of using the menu. Each time you type "insert" it will add another row. Those two clicks per row can really add up when you have a lot of rows! If you type it a few too many times, you can also use the "Delete" key to remove the offending rows. 
    Got your own tricks to share?
    As usual, if you've got your own tips in this area, or a cool reason to use this trick, please leave us a comment for the team to see and the community to gain.
  • Microsoft InfoPath 2010

    Download the Beta!

    I'm super excited to announce Microsoft Office InfoPath 2007 Beta and Microsoft Office Forms Server 2007 Beta for browser-enabled forms, so you can install both of them today.
    After registering you'll get to select which products you want, which should include:
    • Microsoft® Office Professional Plus 2007 (includes InfoPath)
    • Microsoft® Office SharePoint® Server 2007 - Enterprise (includes Forms Services, which is also available standalone as Microsoft® Office Forms Server 2007. Both servers have 64-bit options.)
    All are available in English, French, Spanish, German, and Japanese, so tell your friends!
    - Ned and the whole exuberant InfoPath team
  • Microsoft InfoPath 2010

    Improvements to Share Point integration - Property demotion

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

    InfoPath Quick Tip: Exporting InfoPath forms to Word


    Want to export your InfoPath form view to a Microsoft Office Word document?

    The easiest way to do this is to export your InfoPath form to an MHT file using File | Export To | Web... while filling out your form. Then, just open the MHT file in Microsoft Office Word.  The Word document that you create based on the MHT file exported from InfoPath will look very similar to the InfoPath form itself.

  • Microsoft InfoPath 2010

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


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

    More details: .  English SP1 download is here.

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

    InfoPath 2003 SP1 Preview and Office 2003 SP1

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

  • Microsoft InfoPath 2010

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


    Part 2 – Postbacks and conditions that cause them

    Welcome to the second article in our series on optimizing the performance of browser-enabled forms designed with Microsoft Office InfoPath 2007. In our first article, we defined performance in terms of responsiveness. In this article, we’ll focus on postbacks, one of the most common causes of reduced performance

    Postbacks are probably the most important factor affecting form performance because the effect of other conditions is amplified with each postback. There are two significant aspects of postbacks which we’ll examine in this series. First, which form features cause postbacks? Those features are the subject of this article. Second, what kinds of postbacks are more expensive to process, thus imposing an additional burden on the performance and scalability of the form system? We’ll examine those factors in the next article.

    What is a postback?

    Certain form controls, actions, and features require the browser to communicate with the server during the form-filling session. This exchange of data during the session is called a postback, and usually occurs when a form feature needs to send data to the server for processing. After sending the postback request, the browser must then wait for a response before it can update and re-render the form with the new data. In the case of a full-page postback, the browser must stop rendering completely until the whole updated page is returned, blocking user interaction with the form until it has been re-rendered. Alternately, to improve the user experience in the browser, some features use a partial postback, where only a specific part of the form is updated. This allows the user to continue interacting with other parts of the form while the update happens in the background. In either case, however, unnecessary postbacks impose an additional load on both the browser and the server. If you can reduce or eliminate postbacks as you design, develop, and test your forms, you can improve the performance and scalability of your entire form system.

    Browser-enabled form handling compared with InfoPath client forms

    To better understand the effects of postbacks on performance, it is helpful to compare basic form handling of the InfoPath-rich client with InfoPath Forms Services and browser-enabled forms. Whether you are new to InfoPath, or you are familiar with rich client forms but new to InfoPath Forms Services and browser-enabled forms, understanding these basic differences will help you improve your form design and troubleshooting strategies.

    The major difference between the InfoPath-rich client and browser-enabled form systems is that the InfoPath client doesn’t need to communicate with the form server as frequently as the browser does. This is because the InfoPath client processes most forms locally on the user’s computer. In contrast, the browser form relies on the server for a variety of form processing operations, requiring more communication to exchange data between the browser and the form server. Communication in the form of postbacks is a fundamental feature that allows InfoPath to support browser-enabled forms on the Web, but postbacks also make browser forms more sensitive to performance issues.

    Let’s look at two form loading and editing scenarios that further illustrate the difference between form processing in the InfoPath client and browser-enabled form systems.

    In the InfoPath-rich client scenario, when the user opens the form from a SharePoint form library, InfoPath first determines that the form should be opened in the client rather than the browser. After the initial download of a copy of the requested form template, InfoPath opens and renders an instance of the form on the user’s computer for editing. The form instance in the client is an XML document that the client renders in HTML for display. As the user interacts with the form, the InfoPath client processes and renders changes, and might run some custom form code, all within the context of the client running on the user’s computer. Generally, the only time the client needs to connect back to the server is to make additional data connection requests to query from or submit to a data source, to save a partially completed form, or to submit the final form.

    In the case of the browser-enabled form, when InfoPath Forms Services receives an initial request for the form from the browser, the server starts a session for that user’s form-filling session, allocates server resources, and processes the browser-enabled form template to load an instance of the form XML for the session. In addition, if the form requires it, the server might load and run custom form code and load data from a data source. After this initial processing, the server assembles the JavaScript and HTML that represent the form instance to be downloaded to and rendered by the browser.

    Finally, the server sends the response through a Web Front End server over the network to the browser on the user’s computer, which renders the initial download into the form view that the user interacts with. As the user interacts with the form in the browser, some form processing happens in the browser, but more complex form elements and events require a postback to the server for processing.

    During the transmission and processing of the form data, the browser instance of the form must wait for a response and then re-render the updated form. In this communication cycle, each postback request and response set constitutes a roundtrip. Each roundtrip affects the performance and scalability of the form system in terms of throughput, responsiveness, and resource utilization. This impacts both the browser side and the server side, as well as the network.

    As you can see from these two scenarios, a form-filling session in the browser-enabled form system requires substantially more communication than a similar session in the InfoPath client. In addition, more of the browser-enabled form processing is concentrated on the server, especially when multiple form-filling sessions are being served. In contrast, with an InfoPath client form, the form processing is distributed to the user systems. Consequently, reducing the number and complexity of postbacks as you’re designing browser-enabled forms can substantially boost performance.

    Ten common causes of postbacks

    1. Complex calculations

      A calculation can cause a postback when there is a condition that cannot be evaluated in the browser and requires processing by the server. For example, if a calculation requires data that is not loaded in the DOM, then the browser must send a postback to the server and wait for the result. Another condition that will invoke a postback involves any calculation that is out of the context of the current node. For example, you could create an expression such as .\.\.\my:field1+. When the expression is invoked in the form, because it requires traversing up the tree several levels from the current node, it must be sent to the server for evaluation.

    2. Data adapters

      The function of a data adapter is to make a query connection to an external data source, such as an XML file, a database, a SharePoint list, or a Web service, so that a form can receive and be updated with some data from the data source. If a form invokes a data adapter when the form loads, the browser must wait for the data connection, increasing form load time. If the form invokes a data adapter after the form loads, a postback containing the query request is first sent to the form server, which executes the data connection request on behalf of the browser form, adding additional time to the roundtrip.

    3. Multiple binding: data bound to multiple controls

      Multiple binding happens when one piece of data in the form is bound to two or more controls in the same view. This is usually done so that the same data can be displayed in multiple places. For example, you might design a report with several sections to include a single non-repeating field, such as "Report Date", inside a repeating section so that the same date is displayed in each report section. If you design a form this way, then changing the "Report Date" field in one location will update it everywhere because it is multiply bound. Unfortunately, the cost of this multiple binding might be a roundtrip to the server if the binding is more complex than the browser can resolve. In this case, server analysis is required to reliably identify all the controls bound to the same piece of data. In addition, if something is both multiply bound and out of context, then user edits to form fields will always require roundtrips. Other form actions that will cause roundtrips to the server when there is multiple binding include insertion or removal of repeating tables and repeating or optional sections.

    4. Out-of-context binding

      Out-of-context binding describes a situation where a control inside a repeating or optional section is bound to a node that is in a different part of the XML data source tree, outside the group node that contains the repeating or optional section control. When an out-of-context situation occurs in a form, the correct binding may be too complex to determine within the browser. If either the validity or the kind of action—such as a calculation—cannot be determined in the browser, the out-of context binding will trigger a roundtrip to the server to resolve the binding.

      You are most likely to encounter this problem as you’re designing a form in the InfoPath Designer if you first insert a group or control, and then later decide to move that group or control into an optional section. To avoid creating an out-of-context binding, after you drag and drop the control into the optional section, in the data source pane, drag the node the control is bound to into the group for the new optional section. The group or control will then be bound to the correct context.

    5. View switching

      Multiple views are often used to present a specific view to a specific user audience in a workflow. Multiple views are also commonly used to improve the performance of a form; by careful grouping of related items and limiting the number of controls in each view you can improve the form loading and rendering performance compared to placing everything in a single view. However, each time the view is switched, there is a full postback to send the user’s changes to the server, get the new view, and reload it in the browser. If possible, try to group the items on a view so that any controls that might postback do so when the view is switched. Then only one postback occurs when switching the view. A good example of this is using a button to invoke a query connection that returns data for a list, an operation that requires a postback. If the view is also switched when the button is clicked, you improve the efficiency of the postback. Another benefit of this design is that it makes the view switch a user-invoked action, which improves the user’s perception of the form response. By coordinating the postback of controls in the view with a view switch, you not only improve the responsiveness of the form, but also reduce stress on the server and network by eliminating extra postbacks. When designing your form there is no formula for when to use multiple views, so you will need to balance your use of multiple views with the potential design and performance advantages and costs in your user scenarios.

    6. Conditional formatting

      Conditional formatting is commonly used to hide part of a form from view until some condition is met. However, conditional formatting expressions fire every time the form is rendered whether hidden or not. Additionally, all of the data, calculations, and expressions used by fields that are conditionally hidden are still downloaded and can cause extra performance overhead. Thus if anything else invokes a postback, your form will incur this additional overhead. Similarly, if the conditional formatting requires a postback, then there is a postback each time the form is rendered. Although the primary reason for using conditional formatting has more to do with your form design and presentation, there may also be a slight increase in the responsiveness of the form if it uses conditional formatting. This is possible because it can be slower to render something in the browser than to execute the conditional formatting. However, if you need to substantially limit the presentation, consider using multiple views instead of conditional formatting because multiple views generally perform better.

    7. Digital signatures

      For forms that are filled out in Internet Explorer, signing a form uses an ActiveX control that communicates with the server using out-of-band postbacks. The signature operation involves 3 main steps:

      1. Gather client-specific information to be used by the signature data
      2. Server preprocessing to prepare the stored XML document for signing
      3. Apply the final signature

      Each step causes a postback, the first and the last being relatively expensive. This is because the first postback sends, among other things, the data corresponding to the non-repudiation image to be stored in the signature. The last is a full postback that refreshes the browser with the new signed document that has been prepared on the server.

    8. Business logic event handling

      Normally, when a user changes the values of several controls in the browser form, the JavaScript form logic in the browser can optimize the changes, batching them together to avoid a postback for each change. This reduces the number of postbacks to one. However, this optimization is not possible if the form has code or other logic, such as rules or conditional formatting, that listens to data changes in parts of the XML DOM. For example, if a control is bound to a particular DOM element and a listener is present, changes in that control are immediately communicated to the server and the corresponding event handler invoked. The number of extra postbacks depends not only on the number of event handlers, but also on the XPath they use to listen to DOM events. This is because InfoPath XML events bubble. For example, if some form code has business logic with an event handler that listens to a node close to the root node, there will be relatively more postbacks. This is because any browser change affecting one of the descendants of that node will trigger a postback to the server. Consequently, if your form uses form code or any other construct that involves listening to changes, it is important for performance and scalability that you understand and carefully scope events to reduce unnecessary postbacks and server stress.

    9. Custom hosting pages and external page events

      If you are using advanced form techniques such as developing your own ASP.NET page to host the InfoPath Form control, then there are a couple of things you should be aware of. Submitting to a custom hosting page requires full page postback because the XmlFormView control resides on the server and it involves rebuilding the page controls by ASP.NET. In addition, when submitting the form, before the submit is finalized, data is sent back to the browser with a pending submit action added. This pending submit action must then be sent back to the server in another postback to actually complete the submission. If the page is hosted on a SharePoint site, it also must initialize the SharePoint page infrastructure as well. Also, if an XmlFormView control is hosted on a custom ASPX page and the page listens to events from the control, then every operation triggering an event in the XmlFormView control will require full page postback.

    10. Complex XPaths

      In some advanced form design scenarios, you might build your own complex custom expressions or calculations using the "Edit XPath (advanced)" option. Although most common expressions or calculations can run in the browser, those that require more complex XPaths to evaluate may need to postback to the server. The following complex XPath conditions will cause extra postbacks:

      • More than one possible context for a filter
      • Complex XPath that is not used as a filter
      • XPath where the user input  is not a filter
      • XPath filter or rule that references an element that is not in the current view
      • XPath filter that is position-based
      • XPath with inline functions
      • XPath that includes an unrecognized function
      • XPath that includes an extension function that is not supported by the browser
      • XPath has an inner expression
      • Expressions containing inner nodes


    What’s next?

    In our next article we’ll examine some of the conditions that make postbacks more expensive and that affect the performance and scalability of a server system running InfoPath Forms Services.



  • Microsoft InfoPath 2010

    Introduction to Sandboxed Solutions - Sort data in repeating tables using managed code

    Hi. My name is Phil Newman and I'm a program manager on the InfoPath team. In this post, I'd like to introduce you to one of my favourite new features in InfoPath 2010 - Sandboxed Solutions. In InfoPath 2010, forms with code can now be published directly to SharePoint without requiring the farm administrator to approve and upload them! These forms run in a sandboxed environment which protects other resources on the SharePoint server from malicious code.

    In this short video demo, I show how you can add the ability to sort repeating tables in your forms using code.  I use picture buttons in the heading of the repeating table to trigger the code which sorts the table based on the values in the columns. 

    Get Microsoft Silverlight

    About the Code

    In a nutshell, the code puts the XML from the repeating table into an array, sorts the array using built-in .Net functionality, and then writes back into the XML to update the table.

    //Sorts a repeating table.  Takes the parent group node and the index of the column to sort by.

    private void SortTable(string xpathToSort, int columnToSortBy)


    //get the values in an array

    string[][] ValuesToSort = GetRepeatingTableValues(xpathToSort);

    //sort the array

    Array.Sort(ValuesToSort, new StringArrayComparer(columnToSortBy));

    //write the values back to the xml

    SetRepeatingTableValues(xpathToSort, ValuesToSort);


    //Takes an array of arrays and inserts it into a repeating table

    //Assumes that the array and table are the same size

    private void SetRepeatingTableValues(string xpathToSet, string[][] tableValues)


    //Create a navigator on main node supplied in the parameters

    XPathNavigator mainGroup = this.CreateNavigator().SelectSingleNode(xpathToSet, this.NamespaceManager);

    //Clone the first child node of the main navigator and populate it with data

    XPathNodeIterator tableRows = mainGroup.SelectChildren(XPathNodeType.Element);


    //iterate through the existing XML and update the values from the sorted array

    for (int i = 0; i < tableValues.Length; i++)



    XPathNodeIterator thisRow = tableRows.Current.SelectChildren(XPathNodeType.Element);

    for (int j = 0; j < tableValues[0].Length; j++)



    thisRow.Current.InnerXml = tableValues[i][j];




    //Returns an array of arrays of strings representing the values in a repeating table

    private string[][] GetRepeatingTableValues(string xpathToGet)


    XPathNavigator myNav = this.CreateNavigator();

    int rows, cols;

    XPathNodeIterator tableNodes;

    //figure out the dimensions of the table

    tableNodes = myNav.SelectSingleNode(xpathToGet, this.NamespaceManager).SelectChildren(XPathNodeType.Element);

                rows = tableNodes.Count;


    //move to the first row to count the columns


    cols = tableNodes.Current.SelectChildren(XPathNodeType.Element).Count;

    //create an array to store the values

    string[][] tableValues = new string[rows][];

    //get all the rows in the table

    tableNodes = myNav.SelectSingleNode(xpathToGet, this.NamespaceManager).SelectChildren(XPathNodeType.Element);

    //iterate through the rows and write the inner xml of each element in each row to the array

    for (int i = 0; i < rows; i++)



    XPathNodeIterator childNodes = tableNodes.Current.SelectChildren(XPathNodeType.Element);

    string[] rowValues = new string[cols];

    for (int j = 0; j < cols; j++)



    rowValues[j] = childNodes.Current.InnerXml;


    tableValues[i] = rowValues;


    return tableValues;


    //Comparison implementation for array or arrays

    class StringArrayComparer : IComparer


    private int iColumn;

    public StringArrayComparer(int iColumn)


    this.iColumn = iColumn;


    int IComparer.Compare(Object x, Object y)


    string[] xAsString = (string[])x;

    string[] yAsString = (string[])y;

    return xAsString[iColumn].CompareTo(yAsString[iColumn]);



    Requirements for publishing your forms with code as Sandboxed solutions:

    • The Sandboxed code service need to be enabled on the farm
    • You must be a site collection administrator on the site collection you’re publishing to
    • Your form must be domain trust
    • Your form template must be an InfoPath 2010 template
    • InfoPath 2007 form code needs to be upgraded to InfoPath 2010 form code

    Complete sandboxed solution documentation is available here.  Note that InfoPath takes care of packaging and activating the solution, all you need to do is publish your form to a document library or as a site content type.

    I look forward to hearing your comments about this new feature. Let me know what you think!


  • 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

    Protecting Sensitive Data

    Frequently, we find developers using InfoPath as a platform for developing solutions that manipulate sensitive data, may it be financial data, patient records, or performance review forms. This article shares tips on protecting such data.
    First and foremost, you must know that an InfoPath form is a plain-text XML file. A malicious user can read it through Notepad or other text editor, circumventing any InfoPath authentication logic. So if a user has read access to an InfoPath XML form, anything stored in that XML file can be read. Information Rights Management in InfoPath 2007 allows storing encrypted XML; we'll talk more about it below.
    Also remember that an InfoPath form template (.xsn file) is just a CAB archive, containing plain-text files. These files store all client-side form logic. Information Rights Management allows you to encrypt form templates in InfoPath 2007, see more about it below.
    Like with any other client-server application development platform, you can never trust the logic that happens on the client. InfoPath uses the form template to store all form logic; if the user has access to the form template (and they must in order to be able to open any form based on that form template), they can create a hacked version of the template, circumventing any restrictions that the original form author put in place.
    This means that authentication and authorization performed on the client can't be trusted; calculations and data validation have to be re-done on the server. Here is an example of how this strategy can be realized for a simple record-keeping application:
    • Do not store sensitive data in the XML file; instead, store keys in the XML file, and perform queries on load that populate the rest of the data by using a database/web service. If the user is unauthorized (as determined by the server-side logic), return an empty dataset. You can even detect such condition on the client and show a friendly error message.
    • On submit, send the data to a web service and redo all non-schema validations on the server side. For example, if employees should not be able to submit expense reports above $100 without specifying an approver, have your web service process the dataset and verify that this condition is satisfied. 
    It is always a good idea to restrict access to a production form template by assigning read-only permissions to form users, write access to form maintenance staff, and no access to everyone else. This can be done by using permission features of the SharePoint Server or file shares. Even if you install form templates to the users' machines via a logon script, you can still control access to the .xsn file - provided the user is not running as an administrator, you can set their access to the template file to read-only.
    You may want to enable the protection feature for production form templates:
    However, remember that this protection feature is for recommendations only, it is not intended as a security mechanism. This will show the user a nice error message if they accidentally try to open the template in the Design mode, but won't defend the form template against a malicious user.
    Information Rights Management, or IRM, is a new feature for InfoPath 2007; some of you may already be familiar with the concepts from the other apps in the Office 2003 release. IRM allows the form author to protect both the form template and forms based on the template; IRM infrastructure must be in place in the organization to make this possible. Briefly, IRM is a way to encrypt both form templates and forms, allowing form author to specify who can access the template and suggest default rights for forms based on the template:
    Note that IRM is an InfoPath client-only feature, and it will not work in browser-enabled form templates.
    Alex Weinstein
    Program Manager
  • 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

    Digital Signatures: Layout Tricks


    Folks frequently ask whether it is possible to customize the InfoPath user interface around digital signatures. Some want to show the signature at the very bottom of the form; others want to show signatures side-by-side; others want to disable form submissions when the document wasn't digitally signed. In this article, we'll look at different ways you can tweak the form design to make it happen.

    Trick 1: Display signature at the bottom of the view

    InfoPath lets you show digital signature UI ("click here to sign this form") under a signable section; however, this section doesn't have to include any controls! This means that you can have your signable section with controls at the top of the form, some extra content in the middle, and then another section bound to the same nodes in the data source without any controls in it.

    Your design view would look like this:

    Note how the signableGroup here is multiply bound; the first section has the "allow users to digitally sign this section" checkbox unchecked:

    The second one has it checked, which makes the "click here to sign this form" show up; this is how the end result looks at edit-time:

    Trick 2: Disallow Submit if form was not signed

    InfoPath digital signatures are appended to form XML, just like form data. For example, in the form above, nodes under signature1 will store the digital signature when the user adds it:

    Using this fact, we can enforce business rules in our form: for example, what if we don't want to allow form submissions for cases when form is not signed? Let's go to Tools | Submit Options and create two rules:

    1) Show must-sign warning:

        - condition: signatures2 node is blank (this will evaluate to true when no signature was added)

        - action: show a dialog box message "you must sign the form before submitting it"

        - check "stop processing rules when this rule finishes"

    2) Submit to main data source:

        - condition: always applies (unless the first rule fired - we wouldn't get to this execution point then)

        - actions: submit to main data source + show dialog box message "submission was successful"

    Trick 3: Show signatures side-by-side

    Challenge: make a form that has signatures side-by-side at the bottom; additionally, person 3 should only be able to add their signature if previous signer (person 2) already signed the document.

    We already know how to make the signatures appear at the bottom of view (trick 1); we also know how to determine if a signature was added to the document (trick 2). Let's put all of these tricks together into one powerful solution:

    - Create 3 different signed data blocks, one for each person that will be signing the form. Second data block needs to signing a superset of data that the first one signed, etc.  Your data source task pane will look like this: 

    - Place empty sections bound to the items that you want to sign in the columns of that table.
    - Use containing conditionally-formatted sections to show the signing UI only when necessary.

    The resulting layout will look like this:

    I'm attaching a sample form template that has this trick implemented (works in InfoPath 2003 or 2007; save the XSN to your computer before opening it).

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    InfoPath and Yukon: The Details


    In a recent post, I touched upon the reasons why you might want to go with SQL Server XML columns as the storage for your InfoPath forms. In this article, we'll talk about actually making it work.

    InfoPath's strength is working with XML data sources: web services. In the implementation below, we'll write a simple web service that will help us retrieve and submit the data to Yukon.


    Build a resume database for the HR department. We want to store highly structured resumes in a database. Highly structured here is the opposite of freeform: a resume in our scenario isn't a blob of text; we have the graduation date, employment dates, actual titles and other things parsed into data structures.


    Data Structure

    We will store candidate records as XML blobs in a Yukon XML column. Each resume will be stored as a separate record; each record will also have a primary key - a JobCandidateID - to simplify our development. We'll define only one table, called JobCandidate:

    Populate the table with a few Resume XML files that all satisfy the same schema. Store the schema somewhere where the web server can access it.


    Core Implementation in English: we'll write a web service as a middle tier between SQL Server 2005 and the InfoPath form. This web service will have two methods:

    1) GetCandidateRecord: given a JobCandidateID (an integer), return a DataSet (for our purposes, an XSD-typed XML blob) that contains the candidate record. Give me the job candidate ID, I'll give you his resume.

    2) UpdateCandidateRecord: take a JobCandidateID (an integer) and a Resume (an XML document), and update the resume of the candidate with that particular ID to the resume passed in as a second parameter. Nothing fancy, really.


    Core Implementation in C#

    I promised you two methods, here they are. First, GetCandidateRecord.

    public DataSet GetCandidateRecord(int JobCandidateID)
        DataSet result = null;

        using (SqlConnection conn = new SqlConnection(connString))
            SqlCommand command = conn.CreateCommand();
            command.CommandText = @"
                SELECT Resume
                FROM "
    + tableName + @"
                WHERE JobCandidateID = @x"
            command.Parameters.Add("@x", SqlDbType.Int);
            command.Parameters[0].Value = JobCandidateID;
            SqlDataReader reader = command.ExecuteReader();

            if (reader.Read())
                DataSet ds = new DataSet();
                XmlDataDocument xd = new XmlDataDocument(ds);
                xd.Load(new StringReader((string)reader.GetValue(0)));
                result = xd.DataSet;
            return result;

    Things are fairly straightforward here:

    - Open a SqlConnection using ASP.NET credentials (make sure the ASPNET user has read/write rights to the database).

    - Build a simple SELECT statement to return a resume. Recall that the resume is just an XML document stored as-is in the database.

    - Cast the resume dataset into a typed dataset by applying a schema stored somewhere on the web server. Oh, I forgot to tell you - you need a schema :-). Why? InfoPath form needs to know what to expect from the web service, and while InfoPath can infer the shape of the data from the instance, this method is very much error prone. For example, how can InfoPath know of a repeating structure if only one instance was present in a sample XML document? How about choice or optional structures? Because of all of these reasons, you need to provide a typed dataset through your web service.

    - Return the typed dataset for the Resume record.


    Next, let's look at UpdateCandidateRecord.

    public void UpdateCandidateRecord(XmlDocument xml, int JobCandidateID)
        using (SqlConnection conn = new SqlConnection(connString))
            SqlCommand command = conn.CreateCommand();

            command.CommandText = @"
                UPDATE "
    + tableName + @"
                SET Resume = @x
                WHERE JobCandidateID = @y"
            command.Parameters.Add("@x", SqlDbType.Xml);
            command.Parameters[0].Value = xml.InnerXml.ToString();
            command.Parameters.Add("@y", SqlDbType.Int);
            command.Parameters[1].Value = JobCandidateID;

    - Open a SqlConnection

    - Build a simple UPDATE statement to save the resume for a given candidate. Note that you must use SqlCommand Parameters: just concatenating the XML blob won't do.

    - Execute the UPDATE statement. Note that we are replacing the entire resume with the new one; no partial updates are done. This means that simultaneous editing of Resume records won't be possible.


    Basic Form Template

    Now that the web service is set up, we can easily build a form template based on it. The template may or may not be browser-enabled; the method described here works with both. Just launch InfoPath designer, and pick "start from web service" as your data source. Specify GetCandidateRecord as the "receive" piece of the web service, and UpdateCandidateRecord as the submit part.

    InfoPath will ask you for sample JobCandidateID values for the receive web service; since our database already has a few Resumes, we can type in the JobCandidateID for one of them. You may be wondering - wait, I thought InfoPath won't do the schema inference by example! It won't - the dataset returned by your web service will contain a schema (that's why we called DataSet.ReadXmlSchema() in GetCandidateRecord), and InfoPath will use that schema to build your data source tree.

    After you've gone through the initial data connection setup, you'll notice that your main data source tree is correctly populated with the data types from your schema. Complex structures should show up just fine - repeating, optional, choice structures, non-string datatypes, XSD validation... And the Submit button should be configured to save the modified Resumes back to SQL Server.


    1. Why do we have to use a custom web service, and not built-in Yukon web services?
    There are unfortunate technical limitations that currently require you to write a custom web service to work with SQL Server 2005 in a manner described above. The web service is, as you saw, very easy; we know that this is something that can be made better, and will consider addressing this in future versions of InfoPath and SQL Server.

    2. Why not XSD-typed XML columns?
    When InfoPath submits datasets to the web service, it adds dataset tracking information; while you can add optional attributes to your InfoPath-generated schema and upload it to Yukon, this would complicate maintenance quite a bit.

    3. What other resources are available on the topic?
    Be sure to check out this article by S.Y.M. Wong-A-Ton.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Create tabbed navigation using picture button controls


    In the 2nd installment of our "5 for Forms" video demo series, Charlie Han, a program manager intern on the InfoPath team shows how you can use our new picture button control to create tabs to more easily navigate your forms.

    Get Microsoft Silverlight

    (There are additional steps required to create tabs in display views. Click here to find out more.)


  • Microsoft InfoPath 2010

    Extended data validation for the Multiple-Selection List Box in InfoPath 2010


    Hi, Frank Mueller from the InfoPath development team here. The Multiple-Selection List Box (MSLB) control was introduced in InfoPath 2007 to enable users to select multiple items from a list when filling out forms. In this post, I will explain the different ways you can restrict and validate the data entered using this control in InfoPath 2010. I will also cover some advanced tips and tricks.

    In this post:

    Data Validation

    Special behavior in SharePoint List Forms

    Removing Blank Default Values

    Example Usage:

    First let’s look at a scenario where you may want to use the MSLB control. Say, for example, you are building a form for customers to order your company’s products. To be able to more effectively spend the company’s marketing budget in the future, the marketing department would like to know how your customers found the company’s web site. So you’ve added a Multiple-Selection List Box to gather responses to that question.

    Multi-select list box

    Your customers can now select one or more options. If a customer heard about the web site through a channel that is not specified in the Multiple-Selection List Box control, he/she can select the last checkbox and just type in a custom response.

    Data validation

    The marketing department is pleased with the new order form, but many customers do not bother responding to the “How did you hear about us?” question. With InfoPath 2010, solving this problem is very easy.

    In InfoPath 2010, there are two main ways that form designers can restrict and validate the data entered using the MSLB control.

    1. Require that at least one item be selected (At least one selection required) (NEW in InfoPath 2010)
    2. Require that every selected item have a value (Cannot be blank)

    Multi-select list box Properties

    Require that at least one item be selected (At least one selection required) (NEW in InfoPath 2010)

    New in InfoPath 2010, we can now enforce that users select at least one non-blank item by setting the “At least one selection required” property. In most cases, this is the setting that you will want to use.

    When you preview the form, you will notice a red asterisk in the upper right corner of the control, indicating that a selection is required.

    Multi-select list box If you select a blank custom value, an asterisk will appear in the top right hand corner of the custom value text box.

    Multi-select list box All asterisks will disappear as soon as you select an option that is not blank, or you select the custom value text box and type in a value.

    Technical Details

    The new type of data validation is only applicable to repeating fields that are bound to Multiple-Selection List Box controls.

    When setting the property at the field-level (instead of on the control), you will notice that it’s called “Non-empty occurrence required”. This is because the field can be bound to a control other than the MSLB, in which case users do not make selections when using the control.

    You may set any repeating field to “Non-empty occurrence required”, but you will only see an effect when the field is bound to a Multiple-Selection List Box control. “Non-empty occurrence required” is not implemented as an XSD constraining facet, but rather as a special Validation Rule that is stored in the manifest.xsf of your form template. This has the benefit that you can set the data validation even if you are designing a form template based on a locked schema.

    Require that every selected item have a value (Cannot be blank)

    In most cases, the “At least one selection required” property will do you what you need to ensure that users enter the required data.
    In InfoPath 2010, we still support the legacy “Cannot be blank” property. When this property is set, it requires that every item that a user selects from the list has a value. It does not however require that users select an item in the first place.
    When you preview the form, you will notice a red asterisk, whenever you select the checkbox of the custom value text box. This indicates that if the user wants to select this option, a value has to be typed in the text box before the form can be submitted. Once you type some text in the custom value text box, the asterisk will disappear.

    Multi-select list box

    Technical Details

    When a field in an InfoPath form is set to “Cannot be blank”, a minLength constraining facet is applied to the XSD element, which requires that corresponding XML nodes contain at least one character.

    <xsd:element name="field1" type="my:requiredString"/>   
             <xsd:simpleType name="requiredString">
                      <xsd:restriction base="xsd:string">                           
                              <xsd:minLength value="1"/>

    This makes sense for text fields, when the form designer wants to ensure that the person filling out the form has to enter data into the field before it can be submitted for further processing.
          First Name
    The Multiple-Selection List Box control is bound to a repeating field in the form’s data source. When the user fills out the form and makes selections in the control, a new XML node is created for each selection made. If you mark the repeating field that the control is bound to as “Cannot be blank”, InfoPath will ensure that all options selected or entered through the custom value textbox are not blank. However, if no selections are made in the control, no XML nodes are created, and hence the constraining facet of the field is not violated, and the user is not forced to make a selection.

    When would I want to use “Cannot be blank” instead of “At least one selection required”?

    If you want to ensure that users do not select any item that does not have a value then the “Cannot be blank” property can be used.

    In the example below, both “At least one selection required” and “Cannot be blank” are set. The data is not valid because the custom selection is blank.

    Multi-select list box

    In the example below, only the “At least one selection required” is set. The data is valid because at least one non-blank item is selected.

    Multi-select list box

    Advanced Information:

    Special behavior in customized SharePoint list forms

    In a SharePoint list, when you mark a Choice column as required, it requires users to select at least 1 item and for all selected items to have values.

    SharePoint Column Settings

    Marking the field as required in SharePoint, has the same effect as setting both the “Cannot be blank” and “At least one selection required” properties in InfoPath.  For consistency with SharePoint, when customizing a SharePoint list form in InfoPath 2010, only one data validation option, “Cannot be blank” is available.

    Removing Blank Default values

    When designing the order form described above, InfoPath will by default insert a blank default value node for each repeating field. As you preview the form you will notice that the custom value text box at the bottom of the Multiple-Selection List Box control will be checked by default.

    Multi-select list box

    If you wish there to be no default selection at all in the control, you need to remove the default value node.

    1. Click on the File button
    2. Select Form Options under the Form Information tab
    3. Select the Advanced category in the Form Options dialog
    4. Click on the Edit Default Values … button
    5. Click on the pluses in front of the fields to expand the data source until you can see the repeating field that is bound to the Multiple-Selection List Box control
    6. Uncheck the checkbox in front of the repeating field

      Edit Default Values

    7. Click OK to close both opened dialogs
    When you preview your form now, you will notice that the custom value checkbox is not selected by default.

    Multi-select list box

    Frank Mueller
    InfoPath Developer

  • Microsoft InfoPath 2010

    Layout Tips & Tricks


    2D vs. Flow

    One of the first things that experienced form designers will notice when using InfoPath is that layout of controls is not on a 2D design surface – it’s what we call “flow-based”. Controls function like images – or even character glyphs – in an application like Word. You can drag them around and insert them between words and use blank lines or spaces for positioning. To those designers who are used to precise layout using pixel grids or absolute coordinates, this can be disconcerting.

    To experienced web designers, however, this model is very familiar. Web pages have to be designed to layout dynamically based on the target device. When you’re designing a web page you simply don’t know how wide the browser window which will eventually display the page is, how large the fonts are for the user viewing the page, or even what color settings are applicable. And, of course, different browsers display the same content differently even if all other variables are the same.

    InfoPath templates face a similar set of challenges – but in this case, it’s the data and the form that is dynamic. A variable number of records can appear, parts of the form can show and hide, and users can type different amounts of text into controls which grow. A fixed 2D layout for controls simply wouldn’t work.

    Couple that with a desire to have our views be compatible with web standards (XSLT outputting XHTML), and you can see why we built InfoPath with a flow-based layout mechanism.

    Layout Tables

    A lot of the coolest features in the various Office System applications are likely to fall into two buckets: either you’ve never heard of them, or you couldn’t live without them. Here are a few: Format Painter, Styles & Formatting, Fill Down, and Pivot Tables. Once you’ve used any of those, it’s hard to imagine not having them.

    Tables for layout are like that.

    Web designers know that the trick for good dynamic layout is to use tables. Rather than absolute positions, tables allow for 2D layout of controls by expressing constraints and relative positioning. Even tools like the WinForms designer in Visual Studio .NET are moving in this direction, encouraging the use of docking and panels instead of Top/Left/Width/Height. This makes layout tweaks easier and can even make things like localization much more straightforward.

    A few tips for creating layout using tables:

    • If you’re copying an existing paper form, try sketching out a grid for it using a pencil and a ruler. Count how many rows and columns you need, insert that table, and then start inserting controls into the appropriate cells.
    • InfoPath provides a Layout task pane in design-mode which helps you get started using tables, and exposes some of the actions like Merge and Split Cells in a more convenient fashion.
    • When you drag a control into a table cell its width will be set to 100% automatically. Consider using separate cells for static text and for controls.
    • If you are working from a schema, try dragging a group into the view – for example, “myFields”. One of the options should be Controls in Layout Table which automatically creates a two column table with a standard form layout, containing controls with width set to 100%. You can resize the controls automatically by resizing the layout table.

    In the InfoPath 2003 SP-1 Preview we’ve added a few more table features:

    • a “fly-out” Insert Table button on the toolbar to make getting just the right table into the view easier
    • Draw Table – which definitely fits in with the Format Painter as one of the lesser known but essential tricks in your form design arsenal

    If you’ve never used the Draw Table tool, you should try it. Select Table | Draw Table. This will show the Table toolbar, and enter a mode where you can drag out a rectangle using the mouse to create the first cell, and then draw lines across it to split the cell into two. Keep drawing lines to keep splitting cells. You can change the Border Style on the toolbar to change the style of the borders you create, or use the Eraser tool to erase borders – merging cells.

    Layout “Grid”

    Here’s a cool trick from the team. In the SP-1 Preview, there exists the availability to include a background image.  Here’s a sample grid image:

    Copy the above image and save it to your system as a bmp (no loss in fidelity).  Now go into the View properties dialog, click on ‘Use a background picture’.  In the ‘Files of type’ dropdown, select ‘All Files (*.*)’ and finally select the grid image you just saved.  Back in the View Properties dialog, check “Tile horizontally” and “Tile vertically”.  Click OK.

    Now you have yourself a grid by which to align your controls and text by – this is especially useful when aligning controls between layout tables, aligning tables themselves, or in cases where tables just aren’t appropriate.  When you are ready to publish the form, just go back to the properties dialog and take out the background image.   

  • Microsoft InfoPath 2010

    One-to-Many Relationships on Database Connections

    There have been a few questions about how the main database submit data connection works with related tables.  This is an FYI to clear up some of those issues, as I don't think this information ever made it public!
    At least one of the relationships for every pair of related tables must include the left-hand table's primary key (PK) (where A is the left-hand table in "A relates to B on A.ID, B.ID").  Without this stipulation, there may be many records in table A that map to one record in table B along the defined relationship.
    Note also that unique indexes and unique constraints allow nulls, so the primary key must be used in at least one relationship (they don't allow nulls).  Basically, InfoPath enumerates the records to be updated according to the primary key.  This way, the data inserted into the database is well-defined.
    What that boils down to is this:
    • Sufficient relationships:
      • PK --> Non-unique,  Unique, or PK
    • Insufficient relationships (assuming a sufficient relationship hasn't already been defined):
      • Non-Unique --> Non-unique,  Unique, or PK
      • Unique --> Non-unique,  Unique, or PK
    Once you've defined one sufficient relationship (as listed above), then you can define any other additional relationships that you want (they don't have to follow my rules listed above).
    - Forrest
    Software Development Engineer in Test
  • Microsoft InfoPath 2010

    Using InfoPath e-mail forms

    First I’d like to mention that, as part of a recent announcement, the product name for InfoPath “12” is Microsoft Office InfoPath 2007. This is the name I’ll be using from now on in my blog. In my first post I talk about the benefits of browser-enabled forms. I’d like to focus now on the InfoPath rich client and give you a sense of how it can streamline your daily work with InfoPath e-mail forms. If you are familiar with InfoPath SP1 you probably know that it already allows you to send forms as attachments in email. So why is “e-mail forms” a new feature in Office InfoPath 2007? Well, the limitation in InfoPath SP1 is that forms are just regular attachments and they are not integrated in your Outlook email environment. So in Office 2007 we’ve decided to make forms a first class item in Outlook. That means forms can now be viewed, edited, saved, and forwarded similar to email messages, meetings, or tasks. In addition, e-mail forms can leverage Outlook PIM features like categories and follow up to add a new dimension to your forms workflow. E-mail forms now have their own folder type and they even have their own icon J. This tighter integration makes it really easy to work with forms and to leverage all the structured information they provide without having to leave your familiar Outlook environment. Let’s walk thru a short scenario using InfoPath e-mail forms.
    Let’s assume I need to collect information about the computers used by my team. First I need to design a form template to collects this information. For our scenario, InfoPath ships out-of-the-box an Asset Tracking template, which I will use for this example. In order to be sent out safely in email, forms like Asset Tracking need to work only with data from within the form and can contain only declarative logic, no code. Because of these security restrictions we call such forms “restricted” forms. Once the template is completed, I need to deploy it using the Publishing Wizard and selecting the option “to a list of e-mail recipients”. I then need to specify the recipients, add an optional comment, and send out the form. The screenshot below shows the e-mail deployment of my Asset Tracking form:
    When a member of my team receives the form, she clicks “Reply”, which opens the form in InfoPath. She then fills out the computer information and sends the completed form back to me, as shown in the screenshot below. She has the choice to send me an editable XML form, which is the default, or to send back just a read-only view. She can also add a comment related to the form in the “Introduction” field. This comment is in fact metadata that travels with the forms. The same field can be used, for example, to ask her assistant to fill out the asset information for her and, for more complex forms, to give instructions on how to complete the form. Here is an example of a completed asset tracking form (In this case I’ve completed it as a team member and I’m sending it back to myself):
    Note that at design time I could include a submit button in the form. This will let my team members double-click on the form, edit it in InfoPath and then click “Submit” to send it back to me in e-mail, same as if they replied. However, “Submit” will validate the form and will enforce the return e-mail address. This helps if I need to implement a more formal workflow process using e-mail forms.
    Now I’m switching back to being the data collector. I’m expecting to receive a fairly large number of e-mail forms from my team and I want to be ready to process them. To this end, I’m setting up a new Outlook folder to collect the asset data. I right click on Mailbox and select “New Folder”. In the “New Folder” dialog I need to select the option “InfoPath Form Items”, which is new in Outlook 2007, and associates the folder with InfoPath forms. Here is the dialog that creates the “assets” folder for e-mail forms:
    Once I’ve created the folder, I can also create a rule that automatically routes incoming asset forms to this folder. This rule should refer to InfoPath forms, as shown in the Rules Wizard dialog below. Then I need to pick-up the specific form type out of the list of all the templates that have been cached on my local machine. For each incoming message, the rule will check if it is an e-mail form of type “asset tracking” and will route all the matching e-mails to the “assets” folder. 
    Note that forms can be stored in any Outlook folder. However dedicated forms folders will create by default a new e-mail form based on the template associated with the folder. In addition those folders will allow property promotion, as explained below.
    When each form is saved into the “assets” folder, the properties that have been market for data promotion in the template are copied as Outlook properties. The forms in this folder can now be sorted and filtered based on their promoted properties, You may know how useful it is to take advantage of promoted properties in SharePoint form libraries. You can see at a glance the work progress captured in weekly status reports or the results of a team survey. The same experience is now also available on your local machine, using e-mail forms and form folders in Outlook. Like in SharePoint, the data stored in form folders can be aggregated and exported to Excel for further processing. Below is an example of asset forms with properties promoted in the “assets” folder:
    As you can see, in addition to using the properties promoted from forms, I can take advantage of other properties, like Categories and Flags that Outlook provides for all item, regardless of type. In the example above I’ve flagged the machines that need to be replaced, upgraded, or the new ones that have been purchased in the last quarter.
    When I get all the replies from my team, I will go ahead and process the data. As I mentioned before, the data is not in some collection of text e-mail messages that I need to read in order to extract information for my report. It is in a collection of structured forms that I can very easily process and extract the data to report on.
    My next step is to export the data to Excel. I select all the forms in the folder and then select the “Export to Excel” option from the toolbar. This option automatically generates a spreadsheet with all the data mapped from the forms into Excel. Note that the export to Excel is not limited to the promoted properties in my folder but rather to the entire XML of each form in the folder. Once I have all the data in Excel, I create a simple pivot table with the number of laptop, desktop, and lab machines for each functional team and then I chart the data using the new graphics engine. Here is the result of my data gathering scenario using the e-mail form for asset tracking: 
    When should you use e-mail forms?
    We’ve seen how I’ve used e-mail forms to gather asset information from my team. E-mail forms could also be used for many similar scenarios, often ad-hoc, in order to collect data quickly from a group of people, via e-mail. Examples are creating a survey for your department, gathering feedback from customer visits, or collaborating with your team on a status report. The common elements of these scenarios are:
    • The data needs to be structured – otherwise you’d just use regular e-mail
    • The data collection is done ad-hoc – there’s no need to set up a more formal process
    • You own the final results – it is ok for the final results to be collected in your own mailbox
    Once you have the replies, you could process them as needed and/or share the data with your team. In our example, I am the consumer of the collected information. I will export the data to Excel, review it, and order new hardware as necessary. For status report, the team lead will be assembling the report, then will publish it, and present it to the team.
    A broader scenario is using e-mail to make other forms available to your users. Your forms could be part of a formal team scenario like tracking weekly status, a department workflow solution, or an enterprise wide line-of-business application allowing every employee in the company to update benefits or to submit their performance reviews. In all these scenarios, the forms can be delivered, filled out, and submitted in Outlook. We will cover integrated scenarios for e-mail forms in a follow-up post.
    Finally an important benefit of e-mail forms is offline filling. As you may know, form templates are automatically downloaded on your machine on first use. Forms can also be installed as part of a client setup. Once you’ve used a form once on your machine, you can fill out any similar forms offline. To make things even simpler, “restricted” form templates can be included in the same message with the actual e-mail form. A user can download the form in Outlook, open it, fill it out, and submit it back as e-mail form. An additional benefit here is that you can complete the form offline, submit it, and be done. The form will be stored in the Outlook Outbox folder and will be sent out automatically next time Outlook connects to your e-mail server.
    I hope I’ve been able to give you a sense of the value of InfoPath e-mail forms as first class items in Outlook and get you interested in trying them out in Office 2007. I’ll follow up shortly with other posts on new InfoPath features. Stay tuned! I’d also love to hear your thoughts and feedback.
    Tudor Toma
    Group Program Manager
  • Microsoft InfoPath 2010

    MSDN WebCasts: InfoPath 2007

    In April, the InfoPath team will present three MSDN WebCasts introducing the new features available in InfoPath 2007. These three presentations will provide a high-level overview of InfoPath 2007. In the future, we will offer more detailed presentations that dive down into individual features of InfoPath 2007.
    We hope you will join us for the first three InfoPath 2007 presentations. Here is more information about the first three talks including the schedule.
    New Features in Office InfoPath 2007
    Time: Tuesday, April 11, 2006 12:00 PM – 1:00 PM (PST)
    Presenter: Gray Knowlton, SR. Product Manager - Office
    Description: This webcast presents an overview of the new features in Microsoft Office InfoPath 2007 and InfoPath Forms Services. Join us to learn how you can use InfoPath 2007 to automate and extend business processes by utilizing XML and integration standards to connect electronic forms to virtually any application or system.
    Developing, Deploying, and Hosting Rich Client and Browser Forms for Microsoft Office InfoPath 2007
    Time: Tuesday, April 18, 2006 12:00 PM – 1:00 PM (PST)
    Presenter: Kalpita Deobhakta, Program Manager - InfoPath
    Description: Were you aware that you can design Microsoft Office InfoPath 2007 forms for both the rich client and the browser in a single step? This webcast presents the design-once process for InfoPath 2007, and covers debugging, deployment, and improving the performance and scalability of forms. Find out how to host the InfoPath rich client in other applications, and how to tightly integrate InfoPath 2007 forms into Web pages. We also discuss best practices for using the hosted form control to build powerful but easy-to-use solutions.
    Developing InfoPath Forms for Office InfoPath 2007
    Time: Monday, April 24, 2006 10:00 AM – 11:00 AM (PST)
    Presenter: Nima Mirzad, Program Manager - InfoPath
    Description: This webcast presents an overview of Microsoft Office InfoPath 2007 programmability features including the managed object model, template parts, and provisions for third-party hosting. We also discuss techniques for using Microsoft Visual Studio 2005 Tools for Applications (VSTA) and Microsoft Visual Studio 2005 Tools for the Microsoft Office System (VSTO) to develop Office InfoPath 2007 forms.
    Scott Roberts
    Software Design Engineering Lead
    Microsoft Office InfoPath
Page 3 of 12 (298 items) 12345»