When list box entries are looked up in either the form's data source or a data connection, you might end up with the user being presented duplicate options. You can correct this, and display only unique options in a list, by using a filter and the appropriate XPath.

In this task we will create a filtered drop-down list box that presents the user with a unique set of options. Let's start by designing a new blank form.

Add the controls to the view:

1. Open the Controls task pane.
2. Insert a Drop-Down List Box into the view.
3. Insert a 1 column Repeating Table into the view.
4. Type Source Values into the header row of the repeating table.

Populate the drop-down list box:

1. Double-click the drop-down list box.
2. On the Data tab of the Drop-Down List Box Properties dialog box, select Look Up Values In The Form's Data Source.
3. Click the Select XPath button to the right of the Entries text box, and then select group1/group2/field2.

Filter for unique values:

1. Click Filter Data, and then click Add.
2. In the Specify Filter Conditions dialog box, select The Expression from the first drop-down list, and then type the following expression (as shown in Figure 1):

Figure 1. Filtering list options to display only unique values.

3. Click OK four times.

Try it:

Preview the form. Add several rows of values to the repeating table, making sure that some of the values are duplicates, and then examine the options in the drop-down list. As shown in Figure 2, the drop-down list only displays unique values as the XPath expression prevented duplicate values from being added to the list.

Figure 2. The filtered list box displays only unique options.

InfoPath applies our filter as it steps through the values in repeating table to add them to the list box entries. The XPath expression in our filter checks to see whether a my:field2 value in a previous row (my:group2) is identical to the my:field2 value in the current row. If it is, the value is not added to the list.

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

Buttons that display pictures, with or without a text label, are a common practice in Web pages and are extremely useful in certain scenarios. Picture buttons can often convey much more information to a user than text buttons and do so in less space. But InfoPath has no feature that allows you to create such a button. In fact true picture buttons, which require the use of the button element, are not even supported by InfoPath—they will display in the view but will not function. For its buttons, InfoPath uses the input element with the type="button" attribute. These types of buttons only support text labels.

Regardless of this, it is still possible to create a picture button in InfoPath using a background picture—though it will be limited in that the picture will not depress, along with the border and any text label, when the button is clicked. This can be especially frustrating if you remove the border and have no text label because the user will have no visual feedback that they have actually clicked the picture button.

In this task we will create two picture buttons: one with only a picture, and another with a picture and a text label. We will add the pictures as resource files, and then manually modify the view .xsl file to make the buttons display the pictures. Let's start by designing a new blank form.

Add the button pictures as resource files:

1. Select Resource Files from the Tools menu, and then click Add.
2. Locate and select the first picture, and then click OK.
3. Locate and select the second picture, and then click OK twice to close the Resource Files dialog box.

Insert and prepare the first button:

1. Open the Controls task pane.
2. Insert a Button into the view.
3. Double-click the button.
4. On the General tab of the Button Properties dialog box, press Space to clear the label.
   
   InfoPath requires buttons to have a label, so to effectively remove the label you can use a space character for the label text. If you attempt to just delete the label, InfoPath will present a warning dialog box.
   
   
5. On the Size tab, type the height and width of the picture (in this case 126px and 101px respectively), and then click OK.
6. Right-click the button, and then choose Borders And Shading.
7. On the Borders tab of the Borders And Shading dialog box, click None to remove the existing border, and then click OK.
   
   To display a picture on a Windows XP style button in InfoPath, you must remove the border or the background color, or both.

Insert and prepare the second button:

1. From the Controls task pane, insert a second Button into the view.
2. Double-click the button.
3. On the General tab of the Button Properties dialog box, type Publish for the label, and then click OK.
   
   By default InfoPath center aligns the button text label and does not provide a way to change the alignment. We will left align the text label when we edit the view .xsl file.
   
   
4. Right-click the button, and then choose Borders And Shading.
5. On the Shading tab of the Borders And Shading dialog box, select No Color, and then click OK.

Modify the view .xsl file to allow the buttons to display pictures:

1. 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 view .xsl file.
5. Locate the first input element, and then add the following properties and values to the end of the inline style:

6. Locate the second input element, and then add the following properties and values to the end of the inline style:

7. Save the view .xsl file, and then close the text editor.
8. Reopen your form template by right-clicking the manifest.xsf file and choosing Design.

Figure 1. Buttons modified to display a background picture.

Try it:

You should now see the pictures in the buttons, as shown in Figure 1. Preview the form and test both buttons to see how they respond. By using a background picture we are able to accomplish our task of creating a picture button in InfoPath. Though the limitations might prohibit your use of them, in the right scenario they can be very useful.

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

InfoPath view .xsl files contain three or four standard internal style sheets, depending on whether you have specified a color scheme. These can be identified by the attributes controlStyle='controlStyle', tableEditor="TableStyleRulesID", languageStyle='languageStyle', and themeStyle='urn:office.microsoft.com:themeBlue'. Never modify any of these standard internal style sheets. InfoPath often regenerates these, which will cause you to lose any changes you make to them.

You can add your own custom internal or external style sheet to any or all of the view .xsl files in your form template. The best place to add it is after the InfoPath standard style sheets because styles have reverse order precedence, meaning the last value for an identical selector property wins. If both you and InfoPath have specified a value for the border property of the table selector, whichever one appears last will override the value for the same selector property of any preceding style sheet.

You might use HTML and class selectors when writing your own styles. ID selectors will not be useful because InfoPath will not allow you to place an ID attribute on an element in the XSL. This is because InfoPath autogenerates ID attributes when it creates the view.

INTERNAL STYLE SHEETS

Internal style sheets are stored directly in the view .xsl file, just as the InfoPath standard style sheets are. If you want to use the same styles across multiple views you will need to copy the styles from one view .xsl file to another. Let's review the steps to add an internal style sheet.

Add a custom internal style sheet:

1. 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 view .xsl file.
5. Add the following code just below the last style element:

6. Save your view .xsl file, and then close the text editor.
7. Reopen your form template by right-clicking the manifest.xsf file and choosing Design.

Your custom styles should now be visible in the designer. Internal styles must be updated per view .xsl file, which can create inconsistencies if you forget to update one of the .xsl files. If you want to use the same styles across multiple views, you should consider using external style sheets instead. You can always override external styles for a particular view by using a combination of external and internal style sheets.

EXTERNAL STYLE SHEETS

External style sheets exist in separate .css files. They must be added to the form template as resource files as well as referenced in any view .xsl file that will use them. By using external style sheets you maintain a consistent set of styles across all of the views that reference them. Let's review the steps to add a custom external style sheet named myCustomStyleSheet.css.

Add a custom external style sheet as a resource file:

1. Choose Resource Files from the Tools menu.
2. In the Resource Files dialog box, click Add.
3. In the Add File dialog box, navigate to and select the myCustomStyleSheet.css file, and then click OK. Figure 1 shows the file added as a resource.
4. Click OK to close the Resource Files dialog box.

Figure 1. The myCustomStyle.css file has been added as a resource file.

Link to a custom external style sheet from your view .xsl file:

1. 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 view .xsl file.
5. Add the following code just below the last style element:

6. Save your view .xsl file, and then close the text editor.
7. Reopen your form template by right-clicking the manifest.xsf file and choosing Design.

Your custom styles should now be visible in the designer. If you added the link element to the view .xsl file before you added the .css file as a resource, or if you later update the resource file, your updates will not be visible in the designer until you save and reopen your form template. They will, however, be visible in the form preview before you save and reopen your form template.

As long as your internal and external style sheets appear last you should not have any trouble with InfoPath overriding any of your values. However, if a scenario is encountered where a value in one of the InfoPath standard style sheets is still causing you trouble by overriding your value, add the !important declaration to yours. This will force your value to always be chosen.

Finally, it should be noted that inline styles are normally chosen over internal or external styles because they appear last. The !important declaration on an internal or external style will override a value on an inline style unless the inline style also uses the declaration. In other words, the !important declaration also follows the reverse order precedence.

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

If you have installed an application that uses .NET Framework 2.0, you might suddenly find that you can no longer debug your managed code InfoPath forms. This can be very frustrating, but is easily fixed with the following steps:

1. Shut down Visual Studio.
2. Open Notepad and copy the following XML into it:

3. Save the file to the same folder as the InfoPath application as InfoPath.exe.config.

The default folder is C:\Program Files\Microsoft Office\OFFICE11.

4. Launch Visual Studio, open an InfoPath project, and run the debugger.

The file you just created directs InfoPath to run in the context of .NET Framework 1.1 instead of 2.0.

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

InfoPath allows you, the template developer, to manually modify templates to include XSL features that are not directly supported from within the InfoPath designer. These are called Preserve Code Blocks.

To create a Preserve Code Block, simply change the mode attribute for both the xsl:template and the xsl:apply-templates to have a value of xd:preserve.

One known issue is that on roundtripping your template in the designer, InfoPath will move the closing input tag to immediately after the opening tag.

For example:

Will be changed to:

Because of this change, the xsl:attributes will no longer be applied, as they should, to the opening tag. This effectively disables the radio buttons.

To resolve this issue, you must convert your input tag to an xsl:element, as shown here:

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

When working with the contents of a rich text field, or adding content to a view in the designer, you might have some text that you want to remove the formatting from. If there is a lot of formatting, it can be time consuming to try to remove all of it using the menus, toolbars. Luckily, there are alternatives. Two approaches you can use to quickly remove formatting from the selected text are: the remove formatting keyboard shortcut and the Font task pane.

APPROACH 1 – THE REMOVE FORMATTING KEYBOARD SHORTCUT

To quickly remove formatting using the keyboard shortcut, first select the formatted text, and then press Ctrl+Space. This is very quick and convenient and will remove formatting such as font, font size, font color, highlight, bold, italic, underline, strikethrough, superscript, and subscript. There are other kinds of formatting that this approach will not remove. These can be removed using the second approach, described next.

APPROACH 2 – THE FONT TASK PANE

The keyboard shortcut in the first approach removes text-level formatting, but leaves the paragraph-level formatting, such as styles (i.e. headings 1-6), bulleted and numbered lists, indentation, alignment, and spacing.

To quickly remove either text or paragraph-level formatting using the Font task pane , first select the formatted text, and then from the Font task pane, click Clear Formatting to remove text-level formatting, or click Normal to remove paragraph-level formatting. Click both Clear Formatting and Normal will return the text to a completely unformatted state.

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

If you want to display a row number on a repeating table you can use an Expression Box with the XPath set to position(). This is great if all you want to do is show the row number. But if you actually want to store the sequential autonumber in a field, there's a different XPath you can use.

We will assume that you have the following structure representing your table row:

my:Row
    my:Number
    my:FieldX
    my:FieldY
    my:FieldZ

We will also assume that you want my:Number to be automatically populated with the row number, while staying continually updated as rows are inserted and removed.

1. Double-click the Number field in the repeating table.
2. On the Data tab of the Text Box Properties dialog box, ensure that the Update This Value When The Result Of The Formula Is Recalculated check box is selected.
3. Click the Insert Formula button to the right of the Default Value text box.
4. In the Insert Formula dialog box, type the following formula:
   
   

   count(../preceding-sibling::my:Row) + 1

   
   
5. Click OK twice.

Now preview your form and try it out. Whether you insert or remove rows, each Number field has the correct row number stored in it.

To learn more about position() and other ways of numbering table rows, be sure to check out my example form: Identifying a Filtered Table Row Number.

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

If you use a custom schema for your InfoPath form that has a target namespace with no prefix defined, InfoPath will create a default prefix for you following the pattern of: ns1, ns2, . . . nsn. The "ns1" prefix that InfoPath generates just stands for generic "namespace 1".

Here's what a schema root node looks like that will cause InfoPath to autogenerate a target namespace prefix:

If you do not want InfoPath to autogenerate a prefix, you need to specify your own target namespace prefix. Let's say you name the prefix foo; now all of your form elements will be prefixed with foo instead of ns1. Here's what that schema root node looks like:

If your preference is for your form elements to have no prefix at all, you need to make sure you don't declare a target namespace. In XML Schema, it is forbidden to have a prefixless namespace without a target namespace. So your choice here is to completely remove both the target namespace and the prefixless namespace. Here's what that schema root node looks like with this change:

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

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.

PREPARE YOUR .XDF FILES TO OPEN LAUNCH IN INFOPATH

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:

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:

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.

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:

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.

CREATE AN OPEN ACTION FOR THE .XDF FILE TYPE

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

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:

Form template 2:

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

Workaround:

Reenter your text into the Expression Box Properties dialog box.

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

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.

DESCRIPTION:

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:

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.

WORKAROUND:

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

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:

A not optional + required element of type string:

A not optional + not required element of type anyURI:

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:

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

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

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:

6. Save the manifest.xsf file, and then close the text editor.
7. 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.

8. Click Add Action, and then select Show A Dialog Box Message in the Action drop-down list.
9. Type Test Succeeded for the Message.
10. 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:

3. 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 InfoPathDev.com.

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.

DESCRIPTION:

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.

WORKAROUND:

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

I uncovered this problem on 2004.08.20 while transferring some work from a form I had created earlier to a similar form I was working on. Af first I thought it was a curious little thing, but didn't give much thought to it as I was against a deadline. But later that night, it all came back to me and I was able to put together a short repro the next morning. I've reported this problem to Microsoft.

It appears that when copying an Expression Box from one form to another the bindings are lost, even if the schema is identical. During the rebinding process, something snaps in the brain of the Expression Box and suddenly it takes on a whole new personality—specifically, that of a Text Box. Here's the walkthrough to reproduce the problem:

Create the sample forms:

1. Create a new blank form.
2. From the Controls task pane, insert a Text Box into the view.
3. From the Data Source task, insert field1 into the view as an Expression Box.
4. Right-click on the Expression Box and then choose Copy.
   
   
5. Create a second new blank form.
6. From the Controls task pane, insert a Text Box into the view.
7. Paste the copied Expression Box into the view. The control will be unbound.
8. Preview the form.
   
   Everything is as expected, the text box is editable, and the unbound expression box does nothing.
   
   
9. Close the preview.

Repro the bug:

1. Right-click on the pasted Expression box and choose Change Binding.
2. In the Expression Box Binding dialog box, select field1, and then click OK.
3. Preview the form.
4. Hover over the Expression Box. Notice that the border highlights.
5. Click on the Expression Box, and start typing, and then press Tab.
   
   The Expression Box has now become a Text Box.
   
   
6. Close the preview.
7. Delete the Expression Box and reinsert it from the Data Source task pane.
8. Preview the form.
   
   The Expression Box is no longer editable.

One side note is that you get equally strange behavior, with a few extra benign side effects, when you rebind the pasted Expression Box to a Rich Text node.

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