Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    Capacity Planning for SharePoint 2010

    • 0 Comments

    Check out the new Capacity Management Resource Center for SharePoint 2010 that went live when Office 2010 released to manufacturing last Friday, April 16th.  The InfoPath capacity planning document  along with a refresh of the Capacity Planning Tool Kit are now available.

    The Capacity Management Resource Center contains resources to help you with capacity management in your Microsoft SharePoint Server 2010 environment—map your solution design to a farm size and set of hardware that supports your business goals.

  • Microsoft InfoPath 2010

    Complex Data Validation

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

    Case Study #1

    Problem: a form designer wants to use this logic:

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

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

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

    Enter the first three tests.

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

    Click [Modify] and use this syntax.

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

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

     

    Case Study #2

    Problem: a form designer wants to use this logic:

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

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

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

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

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

     

    Alternative Approach

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

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

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

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

    Jerry Thomas
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    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
  • Microsoft InfoPath 2010

    Wizards (and we're not talking Harry Potter)

    • 8 Comments
    I just got back from some customer visits in Washington DC (governments tend to have a lot of forms…) and a common design pattern came up a few times: creating wizard-like forms. Since InfoPath provides all the built in tools to do this, without any fancy XPaths or code, I thought it would be fun to blog about here.
     
     
    Basic wizard
    Let's say you have a form that would be easier to fill out if folks could focus on one section at a time in a specific order. You can provide that experience by putting each section in its own view, and adding Back/Next buttons to navigate between them.
     
    Specifically:
    1. Open you form in design mode
    2. Open the Views task pane
    3. Click Add New View for each section in your form
    4. Copy and paste each section to its own view
    5. Open the Controls task pane
    6. Insert two Buttons
    7. Double click each button to open Button Properties
    8. Change the label for each button to "<< Back" or "Next >>"
    9. Click Rules to open the Rules dialog
    10. Click Add to add a rules
    11. Click Add Action to add an action
    12. For the Action, select Switch Views
    13. Select the view to switch to
    14. Copy and paste your button pairs to each view and update the rules to switch to different views.
     
    You can also provide this experience by adding Conditional Formatting to each section and hiding all sections that don't currently apply, but that can be cumbersome to design since the view can get so big, and I find it harder to manage the flow.
     
    Conditional Wizard
    InfoPath forms are dynamic, and wizard forms are no different. A common pattern is changing what data you collect based on what they selected earlier on. For example, it's tax time, so if I'm filling out a 1040 and select the option button to file as a single, I can skip the step that would ask me about dependents. You can get this in your form by adding a condition to the rule on your "Next" button, and adding a different rule for each view they could jump to.
     
     
    Some wizard pointers
    • Keep it simple. Try to minimize the number of controls on each page of the wizard. In fact, if you can ask for only one piece of information on a given page, your users will thank you. That said, if there is related data, keeping all of it on one page can be easier than having to skip back and forth.
    • Make it pretty. One of the benefits of a wizard is that you're not trying to cram all that data onto one page, so you have room to throw a graphic on the left in addition to a nice header. You can also wrap everything in a table to make sure the Next/Back buttons don't jump around. Eye candy for all!
    • Share where you are. If the wizard isn't conditional, leave the views on the View menu so people can quickly jump around if they want, and see how far they have to go. If the wizard is conditional so you don't want people jumping to the wrong pages, you can hide the views from the View menu using View Properties, but replace it with a chart at the top of each page to let them know how far they have to go. A simple text saying "25% complete" can go a long way.
    • Know when you're done. Presumably the last page of the wizard will submit the data. It's a nice touch to provide a summary of the data they've entered so far, and change the label on the "Next" button to "Finish" or even just "Submit".
     
     
    If you have any more tips on creating wizard forms, our team and the rest of the InfoPath community would love to hear them, so feel free to comment!
     
    Thanks,
    Ned
  • Microsoft InfoPath 2010

    Debugging Browser Forms

    • 3 Comments

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

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

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


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

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

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

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

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


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

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


    Step 3: Attach to the appropriate w3wp process

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

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


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

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

    Scott Heim
    Support Engineer

  • Microsoft InfoPath 2010

    Understanding the InfoPath SP1 URN Form Conflict Dialog

    • 6 Comments

    Background on URNs

    InfoPath SP1 included changes to the mail deployment model to allow for easier ways to distribute form templates to a group.  One of the tools for making this deployment model work is the URN (Uniform Resource Name).  These URNs are generated automatically by InfoPath and should be unique for each new form template you build. 

    Note:  It’s possible to get a URN that’s identical to an existing one, but not very likely.  This will be explained more later on.

    To see the URN for your form template, you can select ‘File | Properties’ when in the Designer.  The URN is listed there as the ‘Form ID’.  It is called a Form ID because it is used in the deployment model to identify a form template that may be opened from different locations.  The URN is generated by combining three sections separated by semicolons based in part on the form template’s properties.  Here’s a sample URN:

    urn:schemas-microsoft-com:office:infopath:blogsample:-myXSD-2004-05-19T20-48-18

    It consists of three parts:

    • Prefix:  [urn:schemas-microsoft-com:office:infopath]
    • Form Name (the filename by default):  [blogsample]
    • The Namespace or Namespace Timestamp:  [-myXSD-2004-05-19T20-48-18]

    Note:  The Namespace Timestamp is used whenever a user starts out building the schema within InfoPath.  If a form template is built from an XML or XSD file which has its own Namespace, then that Namespace will be used. 

    The Conflict Dialog

    Picture of the URN conflict dialog 

    This dialog will appear any time that you open a form template on your machine that has a URN that matches an existing URN that you’ve previously opened and cached, but references a different Access Path (or publish location, URL).  As you can see in the example above, I have a file called ‘blogsample.xsn’ that I’ve opened from My Documents, but the conflict dialog is saying that I’ve previously opened a file with the same URN from my Desktop.  I got myself into this situation by publishing the same form template to two separate locations with the same filename and then opening each of them.  Because the Form Name and Namespace timestamp are identical for both XSNs, so is the URN. 

    There are two options at this point.  I can either open the newer template (Version 1.0.0.2) by clicking ‘Replace Form on Your Computer’ or the older one (Version 1.0.0.1) by clicking ‘Keep Form on Your Computer’.  It is important to note that this dialog does not affect the original copies of these files in any way.  It will only update your local cache and it will update the file that is shown with this Form Name in your Fill Out a Form dialog.

  • Microsoft InfoPath 2010

    InfoPath and SQL Server 2005: Intro

    • 2 Comments

    SQL Server 2005, also known as Yukon, comes with greatly improved XML support. Just look at it: native XML columns - store XML blobs in your records, along with other data types. These XML columns can be typed or untyped; typed here refers to XSD typing, which provides backend data validation. If an XML blob that you're trying to put into an XML column doesn't comply with the schema associated with the column, the insert will fail. Cool, huh?

    There's more cool to it. Meet XQuery - a query sub-language of SQL that can be used to query your XML columns. What does this mean to you? It means that you can do a structure-aware search through XML.

    Imagine: you need to create a training management system. It's a system with a non-trivial schema - each employee will need to take some mandatory courses, there will be education fields for their secondary education... One of the reports you must generate from the system is "show all employees that graduated before year X". How would you have done this yesterday?

    You could create your InfoPath form against a relational database. this would mean that you'd need to start with ERD design (looong... and messy - not all XML structures translate nicely into relational systems: think of choice, recursive, optional sections). Report generation would have been easy afterwards: just do "SELECT employee_id FROM employees WHERE ...". You all know SQL, no need to go too deep here. But recognize the pain you would have to go through with this approach: ERD design, shredding of the XML structures into relational structures. Plus, if you need to make changes to the schema, this becomes painful: non-trivial changes to relational systems are tough.

    You could create an employee profile management form in InfoPath, and store the resulting XML blobs in SharePoint. You'd pull in basic employee data - names, positions, hire dates - from your HR database (let's assume it lives on a separate SQL database). But how would you generate that report? Built-in SharePoint full-text search is obviously not an option here. What you'd probably do is create a custom app that reads in the XML's, parses them, verifies the criteria ("graduation date > X"), and if the criteria is satisfied, spits out the employee id. Scary and complicated.

    Entering today. XML Columns, XQuery and InfoPath.

    Jeez, that sounded too much like a marketing slogan :-).

    What you can today is create an XML column and store entire InfoPath there. No ERD design. Just drop an entire form (one record) into a SQL column. Then, when you want to report on several forms, just use XQuery.

    This not only allows you to answer trivial queries like "show all employees that graduated before year X", but perform true heterogeneous query. Recall: the basic HR database is a separate relational system. The training management system you just built stores XML blobs. How do you connect the two? Just do a JOIN like you would have otherwise! Yes, SQL Server 2005 allows you to do joins between relational and XML data!

    It's hard to underestimate the benefits here. Structure-aware search will frequently give you much better search results, if you know what you're searching for. It can answer semantic queries that full-text search can't answer - and you don't need to shred your data into relational structures.

    You're probably wondering how exactly do you make InfoPath store data in an XML column in Yukon.. Coming soon, in blog theatres near you :-). UPDATE: the next chapter of the story is here.

    Alex Weinstein
    Program Manager

  • 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

    Add C# or Visual Basic to your existing form using VSTO

    • 4 Comments
    Have you ever created an InfoPath form to later discover that you have to write code in order to accomplish something you need?
     
    If so, you have one of two options:
     
    You can use VSTA to add managed code to your form.  It is included in the Office package, but it is turn off by default.  You must go the Add/Remove Programs and customize Office to install it.
     
    -- OR --
     
    You can use VSTO to add managed code to your form which is what this blog entry is about.
     
    When you create an InfoPath Form Template using Visual Studio 2005, you start with the Design a Form dialog.  On the left you’ll see:
     
     
    Choosing one of these options will allow you to create a project using an existing form template.  For example, if you wanted to use a form template from a SharePoint site, you would choose the second option.  You can also choose the last option to import an Excel workbook or a Word document as your form template.
     
    If you've selected an existing form template, you will get a message:
     
     
    If you've selected a form template that already had code behind it, the existing code will be removed from the new form template as well.
     
    VSTO will now create a project based on the form you've selected and you're ready to add code!
     
     
    - Gary
    Software Development Engineer
  • Microsoft InfoPath 2010

    New Demo Video Posted: Creating Forms in InfoPath 2010

    • 0 Comments

    The first in a series of feature demo videos created by the InfoPath Product team is available for your viewing pleasure on Youtube.

    In this video, Bojana Duke, a Program Manager on the InfoPath team, covers the basics of creating forms in InfoPath 2010 using some of our great new features including Page and Section Layouts, Quick Rules, Rules Manager and the Picture Button control.

    To learn more, check out the video on http://www.youtube.com/watch?v=VKJ3A12RfE8.

  • Microsoft InfoPath 2010

    InfoPath 2010 Public Beta is Here!

    • 4 Comments

    InfoPath 2010 LogoThe InfoPath team is excited to announce the release of the Office 2010 and SharePoint Server 2010 public betas! For the 1st time members of the public can download InfoPath 2010. Download it now from www.microsoft.com/2010!

    Here are just some of the highlights in this new release. (For more details, see our earlier What's New in InfoPath 2010 post).

    Quick and Easy Form Design

    • Designing good looking forms has been made easier with our new page layout templates, layout tables, and themes.
    • With our new out-of-the-box rules and improved rules management UI, you can easily add rules to validate data, format your form, or perform other actions with just a couple of clicks, and without any code. 
    • Our new “quick” publish functionality allows you to publish forms in a single click (no more clicking through the Publishing Wizard every time you want to make an update to your forms!)
    • New Controls include the picture button, signature line control and person/group picker which is now available out-of-the-box in the controls gallery.

    SharePoint Integration
    Over the past 3 years of product development, we’ve made huge investments in integration with the SharePoint platform to make it much easier to build rich forms-based applications on top of SharePoint Server 2010.

    • Using InfoPath, you can now extend and enhance the forms used for creating, editing and viewing items in a SharePoint list.
    • With the new InfoPath Form Web Part, you can host your forms on portal pages without writing a single line of code. 
    • With SharePoint sandboxed solutions, forms with code can be published directly to SharePoint libraries without requiring administratror approval.
    • Richer browser forms:Bulleted, numbered, and plain lists, multiple selection list boxes, Combo boxes, Choice group and sections, and Filtering functionality are now supported in browser forms.
    • InfoPath Forms Services Administration and Management: We have invested in many improvements to make it easier to manage InfoPath Forms Services as a component of Microsoft SharePoint Server 2010. These include Powershell commandlets to automate tasks and SharePoint Maintenance Manager Rules to monitor the health of your server.

    New iconIntroduced since the technical preview, InfoPath now supports connecting to REST Web Services.

    Go download the beta now and send us your feedback using Send-a-Smile.

    Enjoy!

    The InfoPath Team

  • Microsoft InfoPath 2010

    Cool Forms! Feature Status

    • 6 Comments

    This week’s cool form is a form used to track the status of testing of feature areas. One interesting decision made in this form is to use questions as labels rather than field names. This makes the form much easier to understand, particularly given that field names for compactness in the list view tend to be only one or two words. Another key aspect of this form design is the use of ‘?’ picture buttons beside certain questions. Clicking one of these buttons provides detailed help text underneath the question. You can see an example of this text in the screenshot in blue. This technique of hiding detailed text until the user asks for it enables the form designer to get the best of both worlds, a form that is compact and easy to read as well as a form that provides enough detail to ensure it is filled out correctly.

    Feature Status Form

    If you have a “cool” form that you would like to share with us, please send an e-mail with the following details to coolform@microsoft.com -

    • Attach 1 or 2 screenshots of your form
    • Provide a brief description of the form
    • You may also attach the XSN file (optional)

    The most popular submissions will be featured on our blog in future posts.

    Check out other Cool Forms here.

  • Microsoft InfoPath 2010

    Extending the InfoPath control set with custom controls

    • 7 Comments
    InfoPath provides a rich and complete set of generic built-in controls in both 1.0 and SP-1, but there are some cases where there is a need for a control that is specific to your form or to your organization.  InfoPath SP-1 provides functionality to let users extend the set of controls available. Form developers can leverage currently existing ActiveX controls and use them within InfoPath. Also, following a few prescribed steps, software developers can write their own ActiveX controls to be used in InfoPath.

    InfoPath’s custom control support allows users to create controls for three different types of binding:

    Simple data type (string, numbers, etc)

    Controls that are written to bind to simple data types would allow a control to do custom processing on data before it gets put into the XML. The control can be designed to have UI that combines multiple simple controls (buttons, textboxes, checkboxes, etc…) to encapsulate them into one control. For example, multiple buttons can be combined with a textbox to make an in-document calculator control. Combining these all into one control will provide a simple way to re-use the same control in multiple forms.

    XML stream

    InfoPath SP-1 allows XML nodes to follow any schema. This allows form developers to work with industry standard XML Schemas. One example is a MathML control that could be written for InfoPath to save XML compliant with the MathML schema and display it in InfoPath form in a meaningful manner.

    IXMLDomNode

    For greater flexibility, InfoPath custom controls can be bound to an IXMLDomNode and any msxml operations can be performed directly on the XML tree.

    Deployment

    Custom controls need not be installed on every form users’ computer before loading the form. Controls can be packaged with your form solution so that on first open, the control will be registered and installed. Controls should be stored in a CAB files and able to self-register.

    Security

    Custom controls in InfoPath have a few security constraints to keep users safe. Firstly, all custom controls used within InfoPath require the IObjectSafety interface to be implemented and the control to be marked as Safe for Scripting and Safe for Initialization. Without these two flags, InfoPath will not load the form and will notify the user.

    In addition, for solution which have controls packaged in the form solution, it is necessary to sign the CAB files with a digital signature. When users open the form for the first time, they will be prompted on whether or not they will accept the control signed with that signature (similar to the ActiveX control dialogs you see in Windows 2k/XP).

    For detailed information on how to write a custom control for InfoPath, see Lab 06 in the MSDN InfoPath 2003 Training. (http://msdn.microsoft.com/library/en-us/odc_ip2003_tr/html/odc_INF_Lab_06.asp)

     

  • Microsoft InfoPath 2010

    Decoding the InfoPath picture format (also Ink Picture)

    • 3 Comments

    InfoPath provides two controls which saves pictures inside the XML form (rather than linking to it). When trying to process this XML file outside of InfoPath, you will need to translate the data back into the image binary. InfoPath picture control data and ink picture control data is stored in the XML as base64 encoded data. You will need to decode the base64 picture into binary before it is usable.

    Below is a code sample in C# that will do it:

    byte[] image = Convert.FromBase64String( s );
    MemoryStream memStr = new MemoryStream();
    memStr.Write( image, 0, image.Length );
    Image img = Image.FromStream( memStr );
    img.Save( filename );

  • Microsoft InfoPath 2010

    Showing a Red Asterisk on a Rich Text Box

    • 1 Comments

    Q: How do I get the red asterisk to show on a Rich Text Box? There isn’t a checkbox for “Cannot be blank” on this type of control!

     

    A: Easy - add a declarative data validation rule for the condition where the field bound to the Rich Text Box “is blank”. To get started, display the control’s properties dialog box and then click Data Validation.

     

    So now you’re wondering – why isn’t there a simple checkbox for that?

     

    Behind the scenes, the “cannot be blank” checkbox actually maps to a change in the schema, rather than a declarative validation rule. For strings we add a length restriction, but for other types it sets nillable="true" (can be blank) or nillable="false" (cannot be blank).

     

    This explains why the checkbox is enabled when using a schema you’re creating in InfoPath and disabled when using a fixed schema from an external source. Since the schema we use for rich text (XHTML) nodes is a complex type the nillable approach doesn’t apply.

     

    So why does a declarative validation rule cause a red star to appear? When the form is running, the validation display semantics don’t distinguish between schema validation, declarative validation, and even code validation if you use an OnValidate event handler and/or add to the Errors collection. The logic for the validation display is:

     

                if( node fails validation )

                {

                            if( string value of node is blank )

                            {

                                        show red star

                            }

                            else

                            {

                                        show red border

                            }

                }

     

     

  • Microsoft InfoPath 2010

    Why doesn't InfoPath have a Password control?

    • 1 Comments

    Q: I want to create a control for entering passwords in an InfoPath form. How do I do this?

    A: InfoPath cannot guarantee the security and privacy of text entered into a password control, so it does not contain such a control.

    But Why?

    A typical password control contains features that make it hard for anyone but the user typing the password to discover what that text is. Password controls may also interact with a secure server so that the password is not sent in clear text, but is instead encrypted. Further, copying the text from a password control is not allowed.

    Because InfoPath allows files to be stored to a user’s local file system, InfoPath will the store the value typed into a field along with the XML. Additionally, InfoPath does not perform encryption of network traffic, meaning field values used as passwords will always be sent in clear text.

    But I still want a password control

    For the above reasons, we discourage using the contents of a field in an InfoPath form for entering and submitting passwords. Additionally, modifying the files used to create an InfoPath view to use the standard HTML password control (e.g. <INPUT type=”password” ID=”MyPassword”>), will not work in InfoPath. The nearest behavior that can be achieved is to format an InfoPath Text Box control to use a symbol font set, such as WebDings or WingDings so that the text being entered cannot easily be read as it is being typed.

  • Microsoft InfoPath 2010

    Do it anyway: Submitting with Data Validation errors

    • 5 Comments
    When building a workflow solution using InfoPath, it is often necessary to enforce data validation for some, but not all users. For example, in a simple expense report workflow, Employee->Manager->Accounting, the manager may be required to specify the cost category. The employee, however, can't provide this data. This means that setting the "cannot be blank" property for the costCategory field in the InfoPath form will not be enough to make this work. In this article, we will explore a technique that will let you use powerful InfoPath data validation capabilities to enforce this business logic correctly.
     
    You may have seen a different incarnation of the same problem - "if only I could submit the form with data validation errors...". If so, read on.
     
    1. Create a node in your data source that remembers the role of the current user; let’s call that node userRole. Create rules or code to get that node populated on load of the form.

      Trick 1 - acquiring user role. To set the value of a node to the current user role in rules, use the XPath expression xdXDocument:get-Role().

      Trick 2 - acquiring Active Directory username.  If you are using InfoPath 2007, you can get to the username of the current user through the built-in userName function. In InfoPath 2003, the easiest way to accomplish this is to write a simple whoAmI web service (here is a sample implementation), and plug it in to your form template through a secondary data connection.

    2. Setup data validation logic on the costCategory field by using the Data Validation dialog (not through the “cannot be blank” shortcut in the properties dialog).

    3. Add a new "logical and” clause to the data validation condition. This clause will check if the userRole actually requires the field to be filled out. The entire data validation condition will evaluate to false if the userRole doesn't have this requirement, and the error message will not be shown:
     
    This technique will work in both InfoPath 2003 and InfoPath 2007, and it is supported in browser-enabled form templates.
     
    Alex Weinstein
    Program Manager
  • Microsoft InfoPath 2010

    Multi-Select List Box: Requiring at least one entry

    • 2 Comments
    Yesterday I introduced the Multi-Select List Box and talked about how its data source is somewhat special: it binds to a repeating list of fields instead of a single field like the normal List Box does.
     
    When you need to ensure that at least one item is selected in the multi-select list box, you may be tempted to go to Muti-Select Listbox Properties to check the "cannot be blank" property; however, this property will not be available for multi-select list boxes because of their binding. Since a multi-select list box binds to a repeating field, what you really need is something that means "occurs at least once". Here's how…
     
    Visuals - Showing the red asterisk (*)
    1. Insert a multi-select list box and remove its border.
    2. Create a two-column layout table; place the multi-select list box into the first column of that table.
    3. Place an expression box into the second column of the layout table. Use static text * (asterisk) as the contents of the expression box and set its font color to red.
    4. Set up conditional formatting on the expression box:
          if count of elements in the repeating field is greater than 1, hide this control
    5. Set up a visible outside border on the layout table.
     
    The steps provided above will provide a visual indication to the user that the field is required - a red asterisk will be shown whenever the multi-select list box doesn't have any option checked. After you're done, you should see results similar to the following:
     
    Form Design
    Form Filling
     
    Preventing submit
    We still need to make sure that our users can't submit a form with this error - since nothing we've done above prevents form submission. This can be achieved in several ways:
     
    • Option 1: Use rules for form submission
    As the first step of submission, check if count of elements in the repeating field is less than 1. In that case, show an error message and stop processing all rules, essentially preventing form submission.
    • Option 2: Add data validation to another field
    if count of elements in the repeating field is less than 1. This will cause InfoPath to add an error to its Errors Collection behind the scenes if the condition is not met, and your users will not be able to submit the form.
    • Option 3: Write code for the Submit action
    In code you can check the condition and add elements to the Errors Collection as necessary.
     
    - Alex Weinstein
    Program Manager
  • Microsoft InfoPath 2010

    “Invalid Data” error when calculating the result of 2 or more fields

    • 1 Comments

    When you create a calculated field in an InfoPath XML node (field) you may find that some of the resulting calculations produce an “Invalid Data” error:

    InvalidDataError

    This behavior is a known issue when doing floating point calculations and is *not* specific to InfoPath or Microsoft for that matter. The floating point calculation behavior is explained in detail in several articles on the Internet; however, here are a few for reference:

    Sun Microsystems: What Every Computer Scientist Should Know About Floating-Point Arithmetic
    http://docs.sun.com/source/806-3568/ncg_goldberg.html

    Lahey Computer Systems: The Perils Of Floating Point
    http://www.lahey.com/float.htm

    To create a sample of the above result:

    - Create a new SQL Server or Access database table named: FloatingPointTest

    - Add the following fields and data types:

    • ID (Int, No Nulls, Primary Key)
    • Quantity (Int)
    • Price (Money)
    • Total (Money)

    - Create an InfoPath Form Template based on this table

    - When complete, your data source should look like this:

    DataSource

    - Add the “FloatingPointTest” repeating group to the View as Repeating Section with Controls

    - Set the Default Value property of the Total field to the expression: Quantity * Price

    DefaultValue_TotalNode

    - Preview the form

    - Enter a value of 1 for the quantity and 2346.76 for the Price – result: the Total field displays the correct result

    - Modify the quantity to a value of 6 – result: the Total field displays the correct result but the control has a red-dashed border indicating an invalid value.

    SampleErrorResult

    The reason why the invalid data appears on some values and not on others has to do with the representation of the floating point value. For example, values ending in .25 (1/4 fraction or multiples of it) can be represented exactly, while other values cannot. The following link from the Microsoft Knowledge Base provides a Tutorial to Understand IEEE Floating-Point Errors.

    Tutorial to Understand IEEE Floating-Point Errors

    http://support.microsoft.com/kb/42980

    This behavior is easily corrected in InfoPath by modifying the calculation to use the “round” function. In this sample, we are looking to have a result with 2 decimal places –as such, our expression would be modified to: round((@Quantity * @Price) * 100) * .01

    Round_Expression

    After making this modification and previewing the form, the same test values now produce a valid result:

    ValidResult

    Dragos Barac
    Senior Development Lead
    Filed Under: Controls, Formulas and XPath

  • Microsoft InfoPath 2010

    InfoPath Forms Services and AJAX

    • 0 Comments

    There's been lots of well-deserved hype lately around Web 2.0 and the technology that's fueling it, AJAX. We're receiving lots of questions such as "do InfoPath browser forms support AJAX?". The answer is more complex than just yes :-); this article aims to clarify any ambiguities here. But first, some definitions.

    What is AJAX?

    Definition from Wikipedia: Ajax, shorthand for Asynchronous JavaScript and XML, is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This is meant to increase the web page's interactivity, speed, and usability. 

    What is a postback?

    After a page has been loaded, a postback is defined as a subsequent browser request to the web server. Ajax is about asynchronous postbacks - those that allow the user to continue working with the page while the refresh happens.

    Does InfoPath Forms Services use AJAX?

    For a broad set of user actions while editing the form, there will be no postback to the server at all - way faster than an asynchronous postback – and the HTML will be incrementally updated, with no flash. This is because InfoPath Forms Services is capable of translating the declarative logic you've placed in the form into dynamic JavaScript snippets.

    Such client-side operations work for actions such as inserting and deleting sections or table rows, conditional visibility or formatting, validation errors, calculations, firing rules to modify data, etc.

    Cases where postback will occur have one thing in common: there's something that absolutely cannot be evaluated on the client, and thus has to be sent to the server for evaluation. For example:

    - there is managed code in the form which needs to run (e.g. AfterChange event)

    - there are complex XPath expressions used for a calculation, condition for a rule etc   

    When postback does need to happen it generally uses an XMLHTTP postback out-of-band; it does not involve a full page postback. The HTML can therefore be incrementally updated.

    How can I tell when the postbacks will happen?

    We'll only touch on this subject very briefly - expect more content on this soon. InfoPath Design Checker, in conjunction with InfoPath Forms Services, will provide you insights on the user actions that will cause a postback. It will also provide suggestions as to how to avoid these postbacks. Here's how to see these suggestions:

    1. Make sure that your form template is browser-enabled by going to Tools | Form Options | Compatibility, and checking "Design a form template that can be opened in a browser or in InfoPath".

    2. In the same dialog, provide a URL to a server running InfoPath Forms Services:

    3. At the bottom of the Design Checker task pane, click Options, then check the "Show Browser Optimization Messages" checkbox:

    4. Observe the postback optimization messages in the design checker task pane:

    We'll follow-up with a separate article on ways to interpret these messages, and tips and tricks around improving form postback experience.

    AJAX and forms hosted in a custom ASPX page

    You can create custom ASPX pages hosting the InfoPath form control (XmlFormView; more on it here). Everything within the form still uses the above AJAX architecture. But if you need code-behind the page to communicate between the InfoPath form and other ASP.NET controls in the page, then those events will trigger a full-page postback.

    Office Forms Services and ASP.NET AJAX framework

    In MOSS 2007, we don't offer integration with the ASP.NET AJAX framework (also known as Atlas) to allow for partial postbacks involving communication with other ASP.NET controls in the page. Another thing to note is that InfoPath XmlFormView control will not work inside an ASP.NET AJAX UpdatePanel. At this point, there is no workaround to make it work. Integration with the ASP.NET AJAX is a frequent customer request; we're carefully considering it for future releases.

    Alex Weinstein
    Program Manager
    Alexei Levenkov
    Software Design Engineer

  • Microsoft InfoPath 2010

    Associating a Custom Document Information Panel with an Office Document

    • 2 Comments

    When a custom Document Information Panel is associated with an Office document and/or template, the information needed to locate the Panel is contained in a custom XML data part stored with the document.
    I won’t go into the details of the way an Office Open XML document is structured here (needless to say there are many great resources for this on the web), but the format is basically a ZIP file with a collection of XML files that describe the contents of the word processing, spreadsheet, or presentation. Those XML files are linked to each other via logical “relationships” that define the necessary semantics (e.g. that one file contains the content for the header).

    In the terms familiar to the Office Open specification, a custom XML data part is stored at the following location in an Office Open XML document:

    Basically, the data is stored in an XML file which is logically related to the main part for that file type, and whose logical relationship is of type “customXml”.
    Now then, the other half of the definition of a custom Document Information Panel is the content of that custom XML data part. Here’s an example of the data stored in the custom XML data part for a custom Document Information Panel:

    <customPropertyEditors xmlns="http://schemas.microsoft.com/office/2006">
          <showOnOpen>
                true
          </showOnOpen>
          <defaultPropertyEditorNamespace>
                http://schemas.microsoft.com/office/infopath/2003/myXSD/2005-10-21T21:12:27
          </defaultPropertyEditorNamespace>
          <customPropertyEditor>
                <XMLNamespace>
                        http://schemas.microsoft.com/office/infopath/2003/myXSD
                </XMLNamespace>
                <XSNLocation>
                        \\contoso-server\forms\assetForm.xsn
                </XSNLocation>
          </customPropertyEditor>
    </customPropertyEditors>

    This part defines the settings for the Document Information Panel by using the following four elements:

    Element Name Definition
    showOnOpen This element specifies whether the Document Information Panel should automatically be displayed when the document is opened and the first time it is saved.
    defaultPropertyEditor This element specifies which Document Information Panel template should be shown first when the Panel is made visible (either automatically or by the user).

    The contents of this element are one of two choices:
    Standard properties – this setting shows the default Office 2007 property template
    <custom XML namespace> - if the template to be shown should be a custom Document Information Panel stored with the document, its root XML namespace is stored in this element, so Office can locate and display this information automatically when the Document Information Panel is shown

    XMLNamespace The root XML namespace of the custom Document Information Panel. If this template is the one which should be shown automatically, this value is the same as the value of the defaultPropertyEditor element.
    XSNLocation The location of the InfoPath form template to be shown in the Document Information Panel. This location can be of either of the following forms:
    • File path to the InfoPath form template.
    • The URN of the form template if it is a template installed on the target computer.

    With that information defined, Office automatically locates a custom Document Information Panel and displays it as requested. Note that none of these steps involve using Office to set up the Document Information Panel – this process can be automated without Office (for example, to add a Document Information Panel to a template as part of a server-based process).

    Alnur Ali
    Program Manager

  • Microsoft InfoPath 2010

    Difference between an InfoPath Form and InfoPath Form Template

    • 1 Comments

    What's the difference between a form and a form template?

    We've had some people ask us about the difference between a form and a form template. It's easy to confuse the two--partly because people often expect them to be the same thing, and partly because of how we use the terms in InfoPath.

    When you design a new form in InfoPath--say, a status report for your department to fill out, you're actually creating a form template. This is the file that defines the data structure, appearance, and behavior of the forms that your users fill out. The form template usually has an .xsn file name extension, and actually consists of several files that have been compressed into one, including one or more XML schemas, an XSLT file for each view in the form, an XML file for the default data, script files or managed code assemblies, and a form definition file (manifest.xsf), which contains information about the components of the form, including how it looks and acts, deployment settings, and data connections.

    After you finish designing the form template, you can publish it so the people in your department can start filling in their status reports. As you might've guessed, each of their status reports is a form. That form is just an XML file that contains the data (and only the data) that's been entered into the form. All the other stuff that makes up the form--the graphical interface, the validation, the data connections--is provided by the form template. Which means that whenever you open a form in InfoPath, that form needs to locate and use the form template to function properly. (Otherwise, you'd just be looking at plain XML data.) To link the form to the form template, InfoPath includes a processing instruction in each form that points to the associated form template. (For those of you wondering how this works when you're offline: When you use a form, the form template is cached on your computer.)

    One last note, for the pathologically curious: For a variety reasons, we often use the term "form" to mean both forms and form templates. For example, there's a  Fill Out a Form command and a Design a Form command on the File menu. We tried using "form template" whenever discussing the .xsn file, but we discovered that the term actually confused more people than it helped. It turns out that people were much more likely to think of what they were designing as a form, instead of a form template. This stems most likely from paper forms, which are always called "forms," whether they're being designed, printed, or filled out. Also, in some cases, it was hard to draw a distinction between forms and form templates: Should the Form Options dialog box be titled Form Template Options, because you access it in design mode, or Form Options, because the choices affect how the forms will look? Finally, a hard and fast rule can make things pretty awkward: Instead of the Design This Form command, for example, we'd have Design the Form Template Associated With This Form.

  • Microsoft InfoPath 2010

    Save the Date! Using Horizontal Repeating Sections

    • 5 Comments
    InfoPath 2007 introduces a new flavor of the repeating section control - horizontal repeating section. It is useful when you want to present or edit repeating data in a structured format. When new items are added, they show up side-by-side with the existing items instead of one on top of the other.
     
    Horizontal repeating section is a new building block for layouts. In my previous post about horizontal repeating tables, we discussed how a horizontal repeating table is a combination of a horizontal repeating section and layout tables. You can make your own new layouts by using this new control.
     
    For example, one cool use of a horizontal repeating section is a "calendar" - style form:
     
    Play with it!
    Download the form template and try a few things (requires InfoPath 2007, and save it to your computer before opening it):
    1. Switch to a different month by using a dropdown on top of the form.
    2. Add a note for a day.
    3. Add a note with an exclamation sign (i.e. "presentation!") - notice the day turning red.
    4. Switch views to the summary view, and observe all appointments as a flat list.
    5. Open the form template in design view, and view its logic by going to Tools | Logic Inspector.
     
    How it's done
    In this form, each day in the calendar is displayed by using a horizontal repeating section; only the header ("Monday, Tuesday, Wednesday…") is static. To accomplish this, we are using several powerful tricks:
     
    1. Calendar generation is completely dynamic. To generate a view of a different month, we are setting the following fields in the form under myFields/currentMonth:
      • firstDay [date field in XML format (YYYY-MM-DD); set to the first day of the month that you want to view the calendar for - i.e. for May 2007, set to "2007-05-01"]
      • numberOfDays [integer; number of days in the month that you want to present; i.e. for May 2007, set to "31"]
      • mondayOffset [integer; weekday of first day of the month; Sunday=0, Monday = 1, Tuesday = 2, etc. I.e. for May 2007 that starts on Tuesday, set to "2"]

      Note that if you wanted to extend this calendar to show additional months, you could do so by adding rules to set these parameters for different months. It's also easy to move this logic to a web service or form code - thus eliminating the need to maintain a static list of months.
       
    2. Horizontal Repeating Sections wrap when placed inside a table. The wrapping point is determined by table width. This allows us to set up a 7-day-long week.

    3. Conditional formatting works just as expected on horizontal repeating sections. This allows us to highlight today's date, set red background for days marked with an exclamation sign, and set correct background color for weekends.

    4. Default values help us create a necessary number of instances of the horizontal repeating section to cover for the longest month, even if it starts on Saturday. We need 6 instances to cover for "blank" days before the first day of the month, plus a maximum of 31 days in a month = 37 instances. To accomplish this, you can follow the technique from this article.

    5. Rules provide a mechanism for month selection: when a month is selected from the dropdown on top of the form, correct values are set for nodes under myFields/currentMonth.
     
    Of course, there are many uses beyond a calendar, otherwise we would have just built a calendar control, but we couldn't resist sharing this example because it shows off so many tricks.
     
    Alex Weinstein
    Program Manager
  • Microsoft InfoPath 2010

    Adding a Data Connection to Some WebServices Cause InfoPath 2003 to Disappear

    • 5 Comments

    When adding a web service data connection to an InfoPath 2003 form template, there is a bug that will cause InfoPath 2003 to disappear if the web service’s WSDL contains a particular recursive schema construct.  The following snippet of XSD illustrates the issue:

     

    <xs:element name="RecursiveRoot">

    <xs:complexType>

    <xs:sequence>

    <xs:element name="Branch1" minOccurs="0">

    <xs:complexType>

    <xs:sequence>

    <xs:element ref="ns:RecursiveRoot " maxOccurs="unbounded" />

    </xs:sequence>

    </xs:complexType>

    </xs:element>

    <xs:element name="Branch2" minOccurs="0">

    <xs:complexType>

    <xs:sequence>

    <xs:element ref="ns:RecursiveRoot" maxOccurs="unbounded" />

    </xs:sequence>

    </xs:complexType>

    </xs:element>

    </xs:sequence>

    </xs:complexType>

    </xs:element>

     

    This XSD contains a recursive structure in which there is more than 1 path of recursion and the recursive root is not marked as an optional element in the XSD when referenced.  InfoPath 2003 will work with the WSDL containing this XSD as expected if both references to RecursiveRoot were optional as illustrated in the following modified XSD (changes in red).

     

    <xs:element name="RecursiveRoot">

    <xs:complexType>

    <xs:sequence>

    <xs:element name="Branch1" minOccurs="0">

    <xs:complexType>

    <xs:sequence>

    <xs:element ref="ns:RecursiveRoot " maxOccurs="unbounded" minOccurs="0"/>

    </xs:sequence>

    </xs:complexType>

    </xs:element>

    <xs:element name="Branch2" minOccurs="0">

    <xs:complexType>

    <xs:sequence>

    <xs:element ref="ns:RecursiveRoot" maxOccurs="unbounded" minOccurs="0"/>

    </xs:sequence>

    </xs:complexType>

    </xs:element>

    </xs:sequence>

    </xs:complexType>

    </xs:element>

     

    If you are having issues with a web service that you own, one work around to this issue with InfoPath 2003 is to modify the WSDL for your web service as shown above.  In the case that this is not an acceptable work around, or you do not own the web service, the following steps will help you work around the problem:

     

    1.      Download the WSDL file for the web service to your local machine

     

    2.      Modify the XSD in the WSDL as shown above

     

    3.      Add a Data Connection to the local version of the WSDL file

     

    If you are setting up a submit or receive/submit web service connection then the following steps are required as well to ensure that the data InfoPath submits to the web service adheres to the original schema:

     

    4.      File --> Extract Form Files to save your form template in an uncompressed format

     

    5.      Remove the modifications made to the WSDL XSD in the copy of the XSD that was added to the form template

     

    If you modify the data connection or add another data connection to this local WSDL file for a submit web service then steps #4-#5 will have to applied again.  If you expect other users to modify the design of this form template then the local version of the WSDL should be stored in a shared location that all designers have access to.

     

    This issue has been reported to the InfoPath team as occurring in the ItemLookup method of the web services that Amazon exposes (http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl).  In the case of this method, the modification that is necessary to avoid the InfoPath 2003 bug (step #2) is the following:

     

    1.       Find the BrowseNode element that contains references to other BrowseNode elements

    2.       Add minOccurs=”0” to the BrowseNode references (these occur under the “Children” element and the “Ancestors” element)

     

    Since ItemLookup is a receive only method, there is no need to modify the form template files by hand (steps #4 and #5).

     

  • Microsoft InfoPath 2010

    How to Enqueue Submits While Offline

    • 12 Comments

    How to Enqueue Submits While Offline

    Applies to: Microsoft Office InfoPath 2003 SP1

    Scenario:

    User fills out forms for a particular form template while the laptop is disconnected from the network.  Upon reconnection, seamlessly syncrhonize the offline forms to a Windows SharePoint Services form library. 

    Solution:

    Using OnSubmitRequest, you can have the code save to the offline folder depending on if we're offline or not, as in the following code, which is written in C# using our Visual Studio .NET Toolkit.  You will also need to add a project reference to System.Xml.dll and the using System.XML; directive to your form code.

      public void OnSubmitRequest(DocReturnEvent e)

      {
     
        if (thisApplication.MachineOnlineState == XdMachineOnlineState.Online)
        {
         // submit to Sharepoint using DAVAdapter
         (thisXDocument.DataAdapters["Submit to Sharepoint"] as DAVAdapter).Submit();
        }
        else
        {
         // We are offline or working offline.
         XmlDocument oDOM = new XmlDocument();
         Microsoft.Office.Interop.InfoPath.SemiTrust.IXMLDOMDocument oWrappedDOM = thisXDocument.DOM;
     
         oDOM.PreserveWhitespace = true;
         oDOM.LoadXml(oWrappedDOM.xml);
         oDOM.Save("C:\\Submit\\Form_"
                + DateTime.Now.ToString("yyyy.MM.dd_HH.mm.ss.ff") + ".xml");
        }
      
        e.ReturnStatus = true;
      }
     

    Then, if you've been offline for a while and a number of files have built up, you can run the following jscript to invoke InfoPath externally and force a submit looping through the files, as below:

     
    var oFileSys = new ActiveXObject("Scripting.FileSystemObject");
    var oSubmitDir = oFileSys.GetFolder("C:\\Submit");
    var oFilesInSubmitDir = new Enumerator(oSubmitDir.Files);
     
    var oApp = new ActiveXObject("InfoPath.Application");
     
    var fso = new ActiveXObject("Scripting.FileSystemObject");
     
    for (; !oFilesInSubmitDir.atEnd(); oFilesInSubmitDir.moveNext())
    {
     var strFileName = oFilesInSubmitDir.item().Name.toLowerCase();
     
     if (strFileName.length >= 4
         && strFileName.lastIndexOf(".xml") == (strFileName.length - 4))
     {
      try
      {
       var oDoc = oApp.XDocuments.Open(oFilesInSubmitDir.item().Path);
       oDoc.Submit();
       oDoc.View.Window.Close();
       
       var f = fso.GetFile(oFilesInSubmitDir.item().Path);
       f.Delete();
     
      }
      catch (e)
      {
       WScript.echo("ERROR: " + e.description);
      }
     }
    }
    oApp.Quit();
     
     
Page 6 of 12 (298 items) «45678»