Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

May, 2006

  • Microsoft InfoPath 2010

    Goodbye WhoAmI! Hello userName()

    Anyone who's tried to get the username of the person filling out their form in InfoPath 2003 knows the WhoAmI web service. That was the only way to get the username without writing Visual Basic or C# managed code and using System.Environment.UserName.
    In InfoPath 2007 we built an easier way.
    Announcing a new formula function: userName()
    Now you can simply set the default value to the current form-filler's username. No code, no data connections, no custom web service. Just use the formula dialog and select the function from the category "All":
    To get a default value like this:
    If that's too easy for you, use it in script
    If you're writing script anyway, or if you need to check this value as part of a bigger algorithm and don't want to persist the username anywhere in the form, then you can also access this value in script:
    Of course, you can also use this in C# or Visual Basic, but you could always use System.Environment.UserName, so that's nothing new.
    Either way requires Domain Trust
    For security reasons, either approach will make your form require domain trust, so you'll need to publish the form to a shared location (like Windows SharePoint Services) for the function to work.
  • Microsoft InfoPath 2010

    Use Visual Studio to create InfoPath forms… without code

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

    Download the Beta!

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

    Cool video on InfoPath in Outlook

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

    Best Practices for Rules

    My forms have a bad habit of accumulating more and more rules as I add more and more functionality over time, so I came up with a set of guidelines to keep those rules clean and orderly.
    Remember that there are four places to add rules
    1. On Button Click (in Properties dialog)
    2. When values change (in Controls and Data Source Properties)
    3. On Submit (in Submitting Forms dialog)
    4. On Load (in Form Options | Open and Save section)
    Give your rules names for the scenario they capture
    Good names will summarize their conditions/actions in a more friendly way: eg "Submit using multiple data connections", or "Cancel query if expenses too high".
    Group rules by condition, but separate actions without conditions
    If more than one action has the same condition, put them together so you can edit the condition only once. Otherwise, put each action in its own rule, so you can easily reorder them independently.
    Use "Stop processing rules" to save retyping conditions
    If there's a case where you don't want to run any of your rules, add a rule that checks that case. It doesn't need to have any actions, just check the box to stop processing rules and put the rule before any of the other rules that would also check that case. For example, if you want to skip some submit logic if the expenses in the form are less than 100, put that condition in its own rule before your submit logic, and just have it stop the rules.
    Use dialog messages to debug while developing
    Dialog messages are great for tracing your rules at runtime, but are usually jarring while filling out the form. If you have a condition message to show, use conditional formatting instead to hide/show a section/expression-box with the message. You can even make the message dynamic by having the expression box look up a value in the data source and setting that value from the rule.
    Know when to use calculated default values vs set a field's value
    The “Set a field’s value” action is best for values that only need to be set/copied once, or for values that are conditional. For values that need to update every time another field changes unconditionally, best to use a calculated default value. Good examples for rules:
    • Demo button that populates an entire form with sample data
    • Copying suggested values from a secondary data source that the users can edit afterward
    • Setting someone’s email address based on their name, but only if the email field is blank beforehand
    Got tips?
    If you've got your own best practices we'd love to hear them! Post a comment to share your insights with the whole community.
    - Ned
  • Microsoft InfoPath 2010

    Auto height for sections

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

    Moving fields in the data source

    As most folks figure out quickly, InfoPath doesn't support drag-and-drop of fields in the data source. There are a lot of technical reasons for this, and even a usability concern that people won't realize they can drag fields onto the form as controls if we also allowed them to drag fields around in the data source. But we've heard enough feedback that changing that has made it onto the long list of possible features for future releases. Keep the feedback coming!
    So how do you move fields groups in the data source?
    One way is to right-click the field or group and select "Move Up" or "Move Down". This is great for novices because it's discoverable, but it's a painful number of clicks if you're an expert who has to move a lot of fields in many forms.
    A trick for the keyboardist
    The fastest way to move a field or group a long distances is:
    1. Open the data source task pane
    2. Type the "F6" key
    3. Click tab until a field in the data source is highlighted in orange
    4. Use the Up/Down arrow keys to select the field you want to move
    5. Hold down the CTRL key and use the Up/Down arrow keys to move the field
    Note that this only moves the field in order, it won't move it as a child of a different group. To do that you still need to right-click the field and select "Move".
    Hope that helps!
  • Microsoft InfoPath 2010


    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:
Page 1 of 1 (8 items)