Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    Using SQL Server 2005 Web Services with InfoPath

    • 11 Comments

    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

    STATE = STARTED

    AS HTTP

    (

       SITE = 'myserver',

       PATH = '/getspecifiedagewebservice',

       AUTHENTICATION = ( NTLM ),

       PORTS = ( CLEAR )

    )

    FOR SOAP

    (

       WEBMETHOD 'GetRecordsWithSpecifiedAge'

       (

          NAME = 'AdventureWorks.dbo.getAge',

          SCHEMA = DEFAULT,

          FORMAT = ROWSETS_ONLY

       ),

       WSDL = DEFAULT,

       BATCHES = DISABLED,

       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

    Do you blog about InfoPath?

    • 11 Comments

    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.

    Alex

  • Microsoft InfoPath 2010

    Help Us Improve InfoPath: Send Us Your Forms!

    • 11 Comments

    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 ipforms@microsoft.com 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

    Tips and Tricks for Making Form Filling Faster

    • 11 Comments

    The less time it takes to fill out your forms, the more time your users can spend on other tasks. Also, odds go up that form fillers will complete forms when they take less time to fill out. This blog post will give you a few tips for speeding up form filling and improving accuracy so your forms are completed faster.

    In this post we will cover

    1. Using defaults
    2. Using contextual defaults for bringing in the current day and user

    Setting up default values

    For questions where one answer is much more common than others, it can be useful to set up default starting values.  The value you choose will appear when the form is opened, but the form filler is still able to change it.

    You can set default values by selecting the control and clicking on the properties pane, and then choosing “Default Value”.

    Let’s say I had a sailboat rental form, and when boats are rented employees need to fill out who checked out the boat, when it was checked out, what type of boat it was, the boat #, and customer information.

     

    Because the sailboat rental place has mostly 24 foot boats, we can set the default Size to be 24 feet.   Now employees won’t have to fill this field out most of the time. To set a default value, select the control (the boat size dropdown), choose the Properties tab, and select Default Value. Type the default value in the box provided. You can set the defaults for text boxes, combo boxes, check boxes and many other controls this way.

     

    Contextual values

    When a boat is being checked out, we need to log the person who checked it out and the date. Most commonly, boats are checked out for today’s date. We want to set the default value of “checked out by” date to be today’s date.

    To set the checked out date to today, select the date control, go to the properties tab, and choose “default value”. Choose the function builder at the right .

    Choose the “Insert Function” button and pick the now() function from the Date and Time Category. Click “OK” until you return to the form.  Now, when users open the form today’s date will be automatically filled in.
    When using today() or now(), the form will update the date when you re-open it unless you uncheck the “Refresh value when formula is recalculated”. Make sure to uncheck this box.

     

    today() vs now()

    today() and now() can both be used to set the default value of a date picker. However, the type of form you have can affect which one you use.

         - Use today() when you have a date-only field.

         - Use now() when your field requires a date and time.

    In general, when using a SharePoint list form, use now(). When using a form library or filler-only form, use today(), unless you have changed the data format of the date field to date and time.

     

    Setting up the default user

    Setting the default value of the Person/Group picker is done through the fields task pane. Show the fields task pane by selecting “Show Fields” on the data tab and expand your Person/Group picker field (in my case, outBy). Click “Show advanced view” to see the detailed view. Right-click on the AccountId and choose properties.

     

    Under default value, choose the function builder  and type userName().
    Again, make sure that “Refresh value when formula is recalculated” is unchecked, so that this rule is only run once and not every time the form is opened. Click Ok.

     

    Repeat this process with the DisplayName (optional) to get the best experience. Now the people picker will default to the person who opens the form.
    When we load the form, the date, boat type, and checked out by fields are already filled out. With half of the fields completed, it will take employees less time to check out boats.

     

    Hopefully, these tips will help you set good defaults and your users will spend less time filling out forms!

    Kate Everitt

  • Microsoft InfoPath 2010

    Use Rules and Filters to Create Cascading Dropdowns in Forms

    • 11 Comments

    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)

    • 11 Comments

    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

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

    • 10 Comments

    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

    • 10 Comments
    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++)

    {

    tableRows.MoveNext();

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

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

    {

    thisRow.MoveNext();

    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

    tableNodes.MoveNext();

    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++)

    {

    tableNodes.MoveNext();

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

    string[] rowValues = new string[cols];

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

    {

    childNodes.MoveNext();

    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!

    Phil

  • Microsoft InfoPath 2010

    Powerful Declarative Logic: Phone Number Parsing

    • 10 Comments

    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

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

    • 10 Comments
    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.
     
    Enjoy,
    ned
  • Microsoft InfoPath 2010

    Download the Beta!

    • 10 Comments
    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!
     
     
    Woohoo!
    - Ned and the whole exuberant InfoPath team
  • Microsoft InfoPath 2010

    Improvements to Share Point integration - Property demotion

    • 10 Comments
    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.
     
    Thanks,
    Anand
    Lead Software Development Engineer
  • Microsoft InfoPath 2010

    Tabs

    • 10 Comments
    In my last post I covered how to make Wizard-like forms. This time I want to talk about another common practice for organizing all the fields in a form: grouping each set of fields onto a "tab" so the user can switch between the sets in whichever order they wish. While wizards are useful in forms with a clear flow, tabs are useful when the same form will be updated multiple times in different places.
     
    In Windows XP, tabs look like this (this screenshot's taken from InfoPath's View Properties dialog):
     
     
    InfoPath doesn't have a built-in Tab Control, but it's easy enough to build one using tables, buttons, and views, so let's do it!
     
    The basic idea
    Here's what to build:
    • Views for the contents of each tab
    • Table with shading to give the visual effect of tabs
    • Buttons for each tab with a rule that switches the view
     
    For example:
     
     
    Then when the user clicks "Details" they switch views to see this:
     
     
    How To, with tricks along the way
    1. Create all of your views (from the Views task pane)
      • Select the same color scheme for each view (use the Color Schemes task pane)
      • Use Background Color on the Format menu to make the background of each view the second color for the current color scheme (the second-darkest color at the top of the color picker)
    2. Insert a layout table (on the Insert menu, click Table)
      • Make it two rows high. The first row will be for the buttons, the second will be for the tab content.
      • Split the first row to make a cell for each view, plus one extra cell to take the remaining horizontal space.
    3. Insert a button into each cell (from the Controls task pane)
      • Add a rule to each button to switch to the corresponding view. Do this even for the current view's button.
      • Make the current "active" button Bold, so it stands out.
    4. Use borders and shading (on the Format menu)
      • Select all the buttons at once (hold down the Control key and click each one), then remove all borders and shading from the buttons (they're invisible except for their label!).
      • Select the entire table, then add borders inside and out using the first color in the color scheme (the darkest color).
      • Select the non-active cells and set their shading to the third lightest color of the color scheme.
      • Select the active cell and the content cell, and set their shading to white.
      • Select the active cell and remove the bottom border so it becomes connected to the content cell.
      • Select the right-most "extra" cell and remove the top and right border
    5. Copy the table to each view
      • Update the borders and shading to change the "active" cell for each view
      • Put all your fields for each tab in its content cell
     
    Getting fancy
    If the tabs above aren't pretty enough for your form, add some images inside a few more table cells around each button to provide rounded corners and other visual effects. It's more work, and requires some image editing, but with a little elbow grease you could get something as schmancy as this:
     
     
     
    Enjoy,
    Ned
  • Microsoft InfoPath 2010

    InfoPath Quick Tip: Exporting InfoPath forms to Word

    • 10 Comments

    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

    • 10 Comments

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

    More details: http://office.microsoft.com/officeupdate/ .  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

    Layout Tips & Tricks

    • 9 Comments

    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

    MSDN WebCasts: InfoPath 2007

    • 9 Comments
    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.
     
    Thanks,
    Scott Roberts
    Software Design Engineering Lead
    Microsoft Office InfoPath
  • Microsoft InfoPath 2010

    One-to-Many Relationships on Database Connections

    • 9 Comments
    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

    • 9 Comments
    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

    Protecting Sensitive Data

    • 9 Comments
    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

    Digital Signatures: Layout Tricks

    • 9 Comments

    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

    • 9 Comments

    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.

    Scenario

    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.

    [WebMethod]
    public DataSet GetCandidateRecord(int JobCandidateID)
    {
        DataSet result = null;

        using (SqlConnection conn = new SqlConnection(connString))
        {
            conn.Open();
            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();
                ds.ReadXmlSchema(@"C:\Inetpub\wwwroot\infopath_yukon\Resume.xsd");
                XmlDataDocument xd = new XmlDataDocument(ds);
                xd.Load(new StringReader((string)reader.GetValue(0)));
                result = xd.DataSet;
            }
            conn.Close();
            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.

    [WebMethod]
    public void UpdateCandidateRecord(XmlDocument xml, int JobCandidateID)
    {
        using (SqlConnection conn = new SqlConnection(connString))
        {
            conn.Open();
            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;
            command.ExecuteNonQuery();
            conn.Close();
        }
    }

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


    FAQ

    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

    • 9 Comments

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

    Enjoy!

  • Microsoft InfoPath 2010

    Displaying Contextual Help in a Custom Task Pane

    • 8 Comments

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

     

    Files you'll need

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

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

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

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

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

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

     

    Construct your help resource file

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

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

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

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

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

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

     

    4. Save the file to a shared location

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

     

    Add the data source that will provide your contextual help data

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

    1. Tools >> Data Connections >> Add

    2. Select Receive Data, then XML Document

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

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

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

     

    Enable the custom task pane in your form template

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

    1. Tools >> Form Options >> Programming

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

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

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

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

     

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

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

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

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

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

    4. Build and save your form template.

     

     

    Make the form template full trust

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

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

    Forrest Dillaway
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    Customize an External List Form in InfoPath 2010

    • 8 Comments

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

    Get Microsoft Silverlight
Page 3 of 12 (298 items) 12345»