September 2004 - Posts - Greg Collins

InfoPath Dev

This Blog


Greg Collins

September 2004 - Posts

  • Launch Files with Extensions Other Than .XML in InfoPath

    If you or your company has been using XML files for a while you may have a large collection of them with file extensions other than .xml. Let's assume that these files have the extension .xdf (XML Data File). InfoPath will allow you to use these .xdf files as main or secondary data sources without renaming their extension. By typing the full path and filename, including the .xdf extension, InfoPath will use your file provided it contains valid XML.

    In this task we will show how to have these .xdf files launch in InfoPath when you double-click them. This can be accomplished with relatively few changes as described below.


    There are a few lines of XML code known as processing-instructions (PIs) that must exist at the top of your .xdf files. These PIs can be found at the top of any existing InfoPath .xml file. You must make sure that you get them from an .xml file created using the form template you expect the .xdf file to open with. You will also need to declare the InfoPath form namespaces on the root element of your .xdf file. Let's take a look at these changes:

    The XML declaration processing-instruction:

    <?xml version="1.0" encoding="UTF-8"?>

    The first line of your .xdf file is the XML declaration PI. You should be able to copy this as is, unless you are using an encoding other than UTF-8. If so, make the adjustment.

    The InfoPath processing-instructions:

    <?mso-infoPathSolution name="..." solutionVersion="" productVersion="11.0.6357" PIVersion="" href="..." ?>

    The second line of your .xdf file is the InfoPath mso-infoPathSolution PI. This is used by InfoPath for a variety of purposes. We won't go into each of the attributes here, but they should match with a form produced by the latest version of your form template.

    <?mso-application progid="InfoPath.Document"?>

    The third line of your .xdf file is the InfoPath mso-application PI. This tells the file system that this file belongs to InfoPath.

    The InfoPath namespaces:

    <RootElement xmlns:xsi="" xmlns:my="..." xmlns:xd="" xml:lang="en-us">

    There can be any number of namespaces declared. You must verify that all namespaces declared in your sample .xml file, produced by your form template, is present on the root element of your .xdf file.


    Now that your .xsd files have the PIs and namespaces added, you need to tell the operating system what to do when you double-click an .xdf file.

    Identify the action required to open in InfoPath:

    1. In Windows Explorer, choose Folder Options from the Tools menu.
    2. On the File Types tab of the Folder Options dialog box, type the letters INFOPA to quickly navigate to the INFOPATHXML file type.
    3. Click Advanced.
    4. Select the Open action, and then click Edit.
    5. Copy the information used to open this file type (you'll use it for your .xdf files)
    6. Click Cancel twice to return to the Folder Options dialog box.

    Set the open action for .xdf files:

    1. Click in the list of file types to set the focus.
    2. Type the letters XDF to quickly navigate to your XDF file type.
    3. Click Advanced.
    4. If an Open action exists, click Edit. Otherwise click New to create one.
    5. Enter the information you copied previously.
    6. Click OK three times to save your settings.

    Try it:

    That's it! Now double-click one of your updated .xdf files to launch it in InfoPath.

    ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on

  • Bringing Expressions Out of the Box

    I uncovered this problem on 2004.09.17. I actually noticed it happening several weeks earlier, but didn't have the time then to find out what was going on. I've reported this problem to Microsoft.

    In order to avoid numerous potential problems, when you copy from one form and paste into another, InfoPath breaks all bindings, removes all rules, conditional formatting, etc. But one place it breaks where it shouldn't is when pasting an expression box with a text value.

    Here's the walkthrough to reproduce the problem:

    Create the first form template:

    1. Design a new blank form.
    2. Insert an Expression Box from the Controls task pane using the following XPath (including quotes):

      “This is a test”

    3. Copy the expression box to the clipboard.

    Create the second form template:

    1. Choose Design A Form from the File menu.
    2. In the Design A Form task pane, click New Blank Form.
    3. Paste the copied expression box into the view.

    4. As shown in the Figure 1, the Expression Box Properties dialog shows the Data Source option as selected, with no XPath specified, instead of the Text option. Yet the control clearly still shows the text we entered.

      Figure 1: The expression box is incorrectly bound.

    At this point your expression box will continue to show the text you typed, but any functionality you attempt to place on the expression box, such as conditional formatting, will fail.

    Let's take a look at the difference between the two forms to see what happened. We'll be looking selections from the view1.xsl file.

    Differences in the view1.xsl file:

    Form template 1:

        <span class="xdExpressionBox xdDataBindingUI" title="" tabIndex="-1" xd:xctname="ExpressionBox" xd:disableEditing="yes" xd:CtrlId="CTRL1" style='WIDTH: 145px'>
            <xsl:value-of select="&quot;This is a test&quot;"/>

    Form template 2:

        <span class="xdExpressionBox xdDataBindingUI" title="" xd:xctname="ExpressionBox" xd:CtrlId="CTRL1" style='WIDTH: 145px'>This is a test</span>

    As you can see there is a significant difference in the view1.xsl file, effectively breaking the expression box.


    Reenter your text into the Expression Box Properties dialog box.

    ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on

  • I Just Can't Focus with This Section in My View

    I uncovered the source of this problem on 2004-09-17 after a tester had a usability issue on some other work I was doing. I've reported this problem to Microsoft.


    A common design scenario that you may want to use it to have a set of option buttons on your form that have associated sections. These sections use conditional visibility to only show the desired section associated with the selected value of the option button set.

    The standard behavior for a option button set is to allow the user to use the arrow keys to move between the option buttons to make a selection. If, however you have a section in the view that is bound to the same data node as the option buttons are, that keyboard functionality fails: focus is lost after the first change in selection. The user must press Tab to regain focus on the control, and then press another arrow, only to lose focus again.

    Here's the walkthrough to reproduce the problem:

    Create the structure to reveal the issue:
    1. Create a new blank form.
    2. In the Controls task pane, click Option Button, and then press Enter to accept the default number of option buttons to insert.

    Test the form with proper keyboard navigation:

    1. Click Preview Form.
    2. Use the arrow keys on your keyboard to change the option button selection.

      This should work correctly at this point.
    3. Close the preview.

    Add the control that prevents proper keyboard navigation:

    1. In the Data Source task pane, right-click on field1 choose More | Section, and then click OK.
    2. Preview the form.
    3. Use the arrow keys on your keyboard to change the option button selection.

      At this point you will find that after making the first selection change focus is lost from your radio button control set and is set on the form body. If you had enough controls in your view to make it scrollable, the view would scroll when you press the Up Arrow or Down Arrow.

    4. Press Tab to reset the focus back onto the option button control.


    Currently I do not know of a workaround other than to just press Tab to reset the focus, or to use the mouse to make a selection.

    ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on

  • The Difference Between Optional and Not Required

    When creating an InfoPath form from an external schema, you might encounter an issue where InfoPath still requires that the field be filled in even though the element or attribute was specified as optional. The solution comes from a proper understanding of the difference between "optional" and "not required".

    To verify whether a field is truly optional, you can open your form template in the InfoPath designer, choose Form Options from the Tools menu and then click Edit Default Values. In the Edit Default Values dialog box you will see that any schema element specified as optional has an active check box next to it. To include this optional field as part of the default XML for a new form, leave the box checked. To exclude it, clear the check box. All of the non-optional elements have a grayed-out check box, meaning you cannot clear the check box.

    The confusion happens when InfoPath still requires that an optional field be filled in. This field may be optional, but it is still required. Required is different from optional. Optional means that the field does not need to be present in the XML. You can have a field that is optional and required, meaning that if it is present in the XML then it must be filled in. To clarify:

    Optional: Does not need to be present in the XML.

    Not Required: Does not need to have a value.

    You can have any combination:

    • Optional + Not Required
    • Optional + Required
    • Not Optional + Not Required
    • Not Optional + Required

    There are differences in how to establish these combinations in your schema depending on whether you have an element or an attribute. Attributes have an additional restriction that could force it to always be required--but there is a workaround.

    Schema Elements:

    In order to set a schema element as optional, you include the minOccurs="0" attribute. In order to set a schema element as not required, you include the nillable="true" attribute. String data types are not required by default, though you can force them to be required. Other data types, such as Boolean, Integer, Date, Time, etc. are all required by default. In order to make one of these data types not required, you must set the nillable attribute equal to true for the element in the schema. Following are a few examples:

    An optional + not required element of type date:

    <xsd:element name="Date" type="xsd:date" nillable="true" minOccurs="0"/>

    A not optional + required element of type string:

    <xsd:element name="Name" type="xsd:string" nillable="false"/>

    A not optional + not required element of type anyURI:

    <xsd:element name="Email" type="xsd:anyURI" nillable="true"/>

    Schema Attributes:

    In order to set a schema attribute as optional, you do not need to add anything as attributes are optional by default; but you might prefer to include the use="optional" attribute. In order to set a schema attribute as not optional, you must include the use="required" attribute. Attributes have no equivalent to the nillable attribute on elements. If you want an attribute to be not required, you must specify the string data type. All other data types will require the attribute to have a value. Following are a couple of examples:

    An optional + required attribute of type integer:

    <xsd:attribute name="number" type="xsd:integer" use="optional"/>

    A not optional + not required attribute of type string, to be used as type dateTime:

    <xsd:attribute name="dateTime" type="xsd:string" use="required"/>

    ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on

  • Use Code to Determine a Rule Condition

    One of the great and power features InfoPath provides is the xdExtension prefix. This feature allows your form to call into your code from areas like conditional formatting. It provides you with greater flexibility in determining the validity of a condition than is available from the InfoPath UI only.

    Although xdExtension works in conditional formatting conditions, it doesn't work in rule conditions because the manifest.xsf file lacks a definition for the xdExtension namespace. Since rules are stored in the manifest, attempts to use xdExtension from a rule condition will fail. Fortunately we can fix this by manually updating the manifest.xsf file to include the appropriate namespace.

    In this task we will manually add the xdExtension namespace to the manifest.xsf file so that we can call into code to determine rule conditions. We will then create a test rule that displays a success dialog box when our call succeeds. Let's start by designing a new blank form.

    Modify the manifest.xsf file:

    1. In the designer, choose Extract Form Files from the File menu.
    2. Select a location to save your extracted form files to, and then click OK.
    3. Close InfoPath to release the lock it places on your form files.
    4. Using a text editor, open your manifest.xsf.
    5. Add the following namespace definition to the end of the xsf:xDocumentClass root element:


    1. Save the manifest.xsf file, and then close the text editor.
    2. Reopen your form template by right-clicking the manifest.xsf file and choosing Design.

    Create the rule condition:

    1. Insert a button into the view
    2. Double-click the button.
    3. In the Button Properties dialog box, change the label to Test xdExtension.
    4. Click Rules, and then click Add.
    5. Name your rule Test xdExtension, and then click Set Condition.
    6. In the Condition dialog box, select The Expression in the first drop-down list.
    7. In the expression text box, type xdExtension:TestXdExtension().

    You can set up your function to accept parameters if you desire and can pass them in from the condition expression.

    1. Click Add Action, and then select Show A Dialog Box Message in the Action drop-down list.
    2. Type Test Succeeded for the Message.
    3. Click OK four times to close all open dialog boxes.

    Create the function to evaluate the rule condition:

    1. Press Alt+Shift+F11 to open the Microsoft Script Editor.
    2. Add the following function to your code:

    function TestXdExtension()
        return true; // Quick test to make sure xdExtension is working

    1. Close the Microsoft Script Editor.

    This function must return a Boolean value. A return value of true is required for the rule actions to be processed.

    Try It:

    1. Preview your form.
    2. Click the button you inserted into the view.

    At this point your rule calls into the TestXdExtension function, which returns true. This causes the dialog box message to appear stating that the test succeeded.

    ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on

  • A Tall Tale About My Field

    I uncovered this problem quite a while ago, but on 2004-09-02 it finally got to me enough, when I needed to actually use a structure like this, to write something about it. I've reported this problem to Microsoft.


    There is an problem in InfoPath where the designer thinks fields are invalid when in reality they are not. This only seems to be a problem when you've got a structure similar to that produced when you insert a repeating table into the view: a group with a repeating group inside. It happens when you create a non-repeating section from the repeating group, and then insert another section, from that same group, inside the first. Fields inserted into that inner group appear invalid in the designer when in reality they are not invalid.

    Here's the walkthrough to reproduce the problem:

    Create the structure to reveal the issue:

    1. Create a new blank form.
    2. Insert a Repeating Table into the view.
    3. In the Data Source task pane, right-click on group2, choose More, choose Section, and then click OK.
    4. Insert field1 and field2 into the new Section.
    5. Insert group2 as a Section into the existing section.
    6. Insert field3 into the inner Section.

      Note that Field 3 has a red exclamation point with a tooltip that says, “field3 (Control cannot store data correctly)

    Test the form to verify the issue:

    1. Click Preview Form.
    2. Enter test data into the Repeating Table fields and the Section field to verify they all work.

      There’s no problem storing data in field3.
    3. Close the preview.

    Examine the XSL:

    1. Extract the form files to a temporary folder.
    2. Open the view1.xsl file
    3. Search for “_1”.

      You’ll see that the xsl:apply-templates and xsl:template are both correct.
    4. Search for “_2”.

      You’ll see that the xsl:apply-templates and xsl:template are both correct.
    5. Close the view1.xsl file.

    The problem seems to be that InfoPath is incorrectly identifying this structure as having invalid fields when they are not.

    You’ll find that if you try to close InfoPath you will get an error message stating, “The form includes a control with an error. Data entered into the control will note be stored. Do you still want to close the form?” Click Yes. The form will reopen just fine (with the supposed error still in it), and you can create and use the forms just fine.


    Currently I do not know of a workaround other than to just try to avoid this sturcture where possible, or to deal with the annoyance of having to click Yes every time you close the form.

    ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on

Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.