July 2004 - Posts - Greg Collins

Prevent the File Download Security Warning

After installing InfoPath 2003 SP1 you may have noticed when you try to open an InfoPath form template (see Figure 1) or form (see Figure 2) from a Web site or from SharePoint that a new File Download dialog box appears. These warning dialog boxes can quickly become annoying. You can prevent these dialog boxes from appearing by following the steps below.

Figure 1. The File Download dialog box for InfoPath form templates.

Figure 2. The File Download dialog box for InfoPath forms.

Prevent the File Download dialog box for InfoPath form templates:

There are two ways to prevent the File Download dialog box for InfoPath form templates. The easiest way to do it is to clear the Always Ask Before Opening This Type Of File check box at the bottom of the File Download dialog box (refer to Figure 1). The second way is to follow these steps:

In Windows Explorer choose Folder Options from the Tools menu.
On the File Types tab of the Folder Options dialog box, Type XSN.

The list will automatically scroll and select Microsoft Office InfoPath Form Template.

Click Advanced
Clear the Confirm Open After Download check box, and then click OK.

Prevent the File Download dialog box for InfoPath forms:

Click in the Registered File Types list box to set focus, and then type INFO.

The Registered File Types list box will automatically scroll and select Microsoft Office InfoPath 1.0 XML Document, as shown in Figure 3.

Figure 3. Selecting the InfoPath XML Document file type.

Click Advanced
Clear the Confirm Open After Download check box (as shown in Figure 4), and then click OK.

Figure 4. Preventing the File Download dialog box from appearing.

Click Close.

With these changes in places, you will no longer receive this dialog box when you open an InfoPath form template or form from a Web site or from SharePoint.

These steps are not easily deployable. However, in the future, another option may present itself. Until then users can either click Open on the dialog box, or prevent the dialog box from appearing by following the steps above.

Posted Jul 28 2004, 04:57 PM by Greg Collins with 1 comment(s)

Filed under: SharePoint, Security, Operating System, Windows Explorer, Warning

Populate a Drop-Down List Box via a Secondary Data Source

One great feature of InfoPath SP1 is the ability to quickly populate a drop-down list box from a variety of data sources. One such data sources is an XML file that has been added to the form as a secondary data source. A common mistake is binding the Drop-down List Box control to the wrong data source.

Secondary data sources are very helpful to keep your main data source clean and pure for holding only essential form data. The values in the secondary data source may be updated during the life of the form, but they are never saved as part of the form. Only the values in the main data source are stored when the form is saved or published.

Binding is something that takes place between a control (such as a Drop-Down List Box) and a data node. When you select a data node in the Data Source task pane and drag it into the view, or right-click and choose a control type, the control in the view is "bound" to that data node--meaning that any value held by the control will be the stored value in the data node.

If a control is bound to a secondary data source, the stored value will persist for the life of the form. Once the form is closed, however, the value is lost. If a control is bound to the main data source, the value will be persisted as part of the saved form.

To correctly use a secondary data source to populate a Drop-Down List Box and have the selected value stored as part of the same form, the control needs to be bound to the main data source, but populated from the secondary data source. This can be done with the following steps:

Insert a Drop-Down List Box control bound to the main data source:

From the Data Source task pane, select Main from the Data Source drop-down list.
Select the data node you want the value to be stored in, right-drag it into the view, and then release in the location where you want the control placed.
From the context menu that appears when you release the right-drag, select Drop-Down List Box.

Populate the Drop-Down List Box from a secondary data source:

Double-click the Drop-Down List Box control.
In the Drop-Down List Box Properties dialog box select Look Up Values In A Data Connection.
Choose the secondary data source from the Data Connection drop-down list.
Click the Select XPath button to the right of the Entries field.
Select the node that will be used to populate the values, and then click OK.
If necessary, use the Select XPath buttons to the right of the Value and Display Name fields to make appropriate node changes.
Click OK to close the dialog box.

Your drop-down list is ready. Its values will be populated from the secondary data source, but the selected value will be stored in the main data source when the form is saved or published.

Posted Jul 28 2004, 11:14 AM by Greg Collins with 1 comment(s)

Filed under: Secondary Data Sources, Lists

Enabling XP-Themed Buttons in Task Panes and Modal Dialogs

One anomaly you will run into if you have the Windows XP Themes turned on and are using a task pane or a modal dialog in your form is that buttons in these HTML pages will look different than those inside the InfoPath form view. This is because the HTML pages within InfoPath do not have this feature turned on. You can correct this by adding the following META tag to the top of your HTML page:

Posted Jul 28 2004, 10:45 AM by Greg Collins with no comments

Filed under: Task Panes

Enable InfoPath E-Mail Features

Most people will never run into this problem, but a few of you will and it could drive you nuts.

The InfoPath application includes the e-mail features Send Form As Attachment in the designer, and Send To Mail Recipient in the editor. These are both found under the File menu. If for some reason these are not present, one or more issues will need to be resolved. The three most likely issues are as follows:

Outlook is not installed.
Outlook does has no configured profile.
Outlook in not the default e-mail client.

InfoPath 2003 requires Outlook 2003—an older version simply will not work. If either of these two situations are present on your machine, the above e-mail features will not only be disabled, but they will not appear in the menus at all. The Submit Data As An E-Mail Message data connection might still work, but it also might not.

To enable these InfoPath e-mail features, correct the above issues by ensuring that Outlook 2003 is both installed and set as the default e-mail client.

Posted Jul 28 2004, 10:26 AM by Greg Collins with no comments

Filed under: E-Mail, Outlook

Submit to a SQL Database

When creating a new form from a SQL database connection, there are a couple of things to remember in order to enable the Submit To Database feature.

The SQL tables used must have a primary key, unique constraint, or unique index. Without this you will receive the following error in the summary of the Data Connection Wizard:

Submit status: Not allowed - One or more of the tables in the data source do not have a primary key, unique constraint, or unique index.
The SQL database tables must not include the following data types: image, ntext, text. These are considered long data types and are not supported within InfoPath. If your tables include any of these data types you will receive the following error in the summary of the Data Connection Wizard:

Submit status: Not allowed - One or more of the columns in the data source has a long data type (text, ntext, hyperlink or image). Long data types are not supported.
Other things may prevent you from submitting to your database. Here's a couple of other reasons that will prevent you:

Submit status: Not allowed - A table is being used many times

Submit status: Not allowed - A many to one relationship might exist between two tables in the data source.

If you have successfully satisfied the conditions, the summary of the Data Connection Wizard will inform you that submit is enabled. To then submit to your database, perform the following steps:

Drag a Button control into the view from the Controls task pane.
Double-click the new button to open the Button Properties dialog box.
On the General Tab, change the button action to Submit.
On the Submitting Forms dialog box, the Submit To drop-down list box should have the value Database pre-selected. Click OK to accept the defaults.
Click OK again to close the Button Properties dialog box.

That's it -- you're done! You are now set up to submit your form entries to your SQL database.

Posted Jul 27 2004, 06:58 PM by Greg Collins with 4 comment(s)

Filed under: Error, SQL, Submit

User Role Evaluation Order

InfoPath evaluates the User Roles in top-down order, as they appear in the Manage User Roles dialog box. But there is no built-in way to reorder these roles. Manually editing the manifest.xsf file is the only way to accomplish this. Here are the steps:

Extract the form files to a folder, and then close the InfoPath designer. InfoPath places a lock on the files it uses. Thus you can't modify the manifest.xsf with the form still open in InfoPath.
Use a text editor to open the manifest.xsf file, and then locate the <xsf:roles> tag.
Cut-and-paste each <xsf:role/> tag into the order you want your roles to be evaluated.
Save the modified manifest.xsf file and close the text editor.
Open the saved InfoPath form and test your changes.

If a user belongs to two or more roles, InfoPath will stop evaluating at the first match. If the Open Rules use the User Role as a condition, let's say for deciding which view to switch to, this can lead to anomalies unless taken into account. To fix a scenario such as this, the Roles will have to be ordered in such a way as to alleviate this, or more Open Rules will need to be added to take this into account, or code will need to be used in place of Open Rules depending on how complex a scenario is required.

Posted Jul 26 2004, 03:54 PM by Greg Collins with no comments

Filed under: Roles

Match Control Sizes to Font Sizes

While developing forms in InfoPath, it is likely that you will one day need a label for a check box or an option button that uses a font size other than the default 10pt. Using a different font size will make the control simply not look right next to the label. Luckily these controls are resizable (this is true for both V1 and SP1).

Using a larger font size is fairly straight forward: it's just a matter of finding the correct control size. But using a smaller font size can start shifting the control around and out of place. This is easily corrected by adjusting the margins on the control.

You can see these techniques demonstrated in my example form: Rightsizing Check Boxes and Option Buttons. Also, the following table lists good control sizes for the InfoPath's standard font sizes.

Font Size	Control Size	Margins (T, L, B, R)
8pt	10px	0px, 4px, 3px, 2px
10pt	20px	n/a
12pt	22px	n/a
14pt	24px	n/a
18pt	30px	n/a
24pt	36px	n/a
36pt	48px	n/a

Posted Jul 24 2004, 01:10 AM by Greg Collins with no comments

Filed under: Option Buttons, Check Boxes

Flaky Data Validation Visuals

STATUS: Fixed in InfoPath 2003 SP1.

SCOPE:

Occurs in both V1 and SP-1.
Not language specific.

DESCRIPTION:

On 2004.07.23, I was sent a form to help track down an issue where dashed red lines that appears when data for a particular field is invalid. After a little playing, I was able to narrow it down to a simple repro. It’s an interesting bug.

REPRO STEPS:

Start with a New Blank Form.
Insert a single row/col table (TABLE_1).
Insert another single row/col table (TABLE_2) inside TABLE_1.
Insert a text box into TABLE_2.
Double-click the text box and change its datatype to a Whole Number.
Preview.
Type invalid characters into the text box (i.e. “abc”). A dashed red border appears.
Move your mouse all around, and click over the text box:

Nothing special happens.
Close the preview.
Add a background color to TABLE_1.
Preview.
Type invalid characters into the text box (i.e. "abc"). A dashed red border appears.
Move your mouse all around, and click over the text box:

Notice that the dashed red border acts flaky, disappearing, etc.

This doesn't happen with a single table, only when there are nested tables. There can be any level of table nesting. Also the background color can be on any table except the one that holds the control for this problem to occur. The datatype does not seem to matter—just that it is invalid. Adding a background color to the control's table does not seem to alleviate the problem.

WORKAROUNDS:

Presently the only known workaround is to either not nest tables, or to make sure that the background color is present only on the inner-most table.

Posted Jul 23 2004, 01:35 PM by Greg Collins with no comments

Filed under: Data Validation, Workarounds, Bugs

Master-Detail Table Row Reordering: Safety Tips

STATUS: Fixed in InfoPath 2003 SP1.

DESCRIPTION:
I uncovered this previously unknown problem on 2004-07-17 while updating the InfoPathDev Web site using an RSS 2.0 Generator InfoPath form I created. I've reported it to Microsoft.

I wanted to reorder the list of InfoPathDev example forms to put the more popular ones at the top. I posted my example form: Reordering Table Rows, which demonstrated how to create buttons to move rows in a table up or down. I use this technique in the RSS 2.0 Generator in a Master-Detail Table. The reordering buttons are in the Master table.

The first row I moved up worked just fine; then when I attempted to move it up again, InfoPath crashed. After that, it crashed time after time. At first I couldn't figure out what was going on—and what was worse was that the debugger commands I placed at the top of the OnClick handlers to attempt to locate the source of the problem were never reached before InfoPath would crash. (I made sure I was a good boy and sent in all of the crash reports.)

While continuing to play, I was able to reorder a table row without a crash. My assumption was correct: the crash was avoided by first selecting the row I was attempting to reorder. When the row was selected, the reordering worked fine, but without the selection InfoPath crashed.

The failure is the following:

CiceroUIWndFrame: INFOPATH.EXE - Application Error
The instruction at “0x30528af9” referenced memory at “0x00000000”. The memory could not be “read”.

This problem doesn't always manifest itself. It seems to be based on the complexity of the contents to be reordered. I have some XML files I have no problem reordering, while others that are more complex and crash every time. I haven't yet tested whether this problem is also manifest using a standard Repeating Table or Repeating Section.

Luckily there is a workaround, even though having to select each row before reordering quickly becomes quite a tedious task.

Posted Jul 17 2004, 02:02 PM by Greg Collins with no comments

Filed under: Repeating Tables, Workarounds, Bugs, Repeating Sections, Master-Detail

Order of Processing at OnClick

In InfoPath, the order of processing when a user clicks a button is:

Rules
Code

When you write your OnClick event handler, take into account that any rules associated with the button will be processed before the code is reached. This can be very useful, but can also create some headaches if not understood.

Posted Jul 15 2004, 10:00 AM by Greg Collins with no comments

Filed under: Rules, Code, Buttons, OnClick

Populate a Drop-Down List Box via Code

NOTE: This article was written for the original InfoPath 2003, which did not support secondary data sources. You can still use code to populate a drop-down list box, but the better approach is to have the drop-down list populate from a secondary data source, and then use code to add nodes to that list in your secondary DOM.

- - - - -

Populating a drop-down list box in InfoPath is easy, but you might need to something more complex than the designer allows. This is possible with some work on your part. Although very powerful, populating a drop-down list box via code requires that you use a Preserve Code Block.

In this task we will populate a drop-down list box via code. The drop-down list box will exist inside of a section that will be used to create the Preserve Code Block. Let's start by designer a new blank form.

Design the view:

Open the Controls task pane.
Insert a Section into the view.
Insert a drop-down list box into the section.

Write code to return a list of options:

Press ALT+SHIFT+F11 to open the Microsoft Script Editor.
Insert the following function:

Java Script:
function PopulateDropdown(sSelectedValue)
{
return "<option value=''>Select...</option><option value='Test'>Test</option>";
}

C#:
public string PopulateDropdown(string sSelectedValue)
{
return "<option value=''>Select...</option><option value='Test'>Test</option>";
}

Save your code, and then exit the Microsoft Script Editor.

Modify the view .xsl file to create a Preserve Code Block:

In the InfoPath designer, choose Extract Form Files from the File menu.
Select a location to save your extracted form files to, and then click OK.
Close InfoPath to release the lock it places on your form files.
Using a text editor, open your view .xsl file.
Locate the xsl:template that contains your drop-down list box.
Replace the mode="_nn" attribute with mode="xd:preserve" for both the xsl:template element and its associated xsl:apply-templates element.

The mode attributes will have matching values in both the xsl:template and xsl:apply-templates elements.

Replace all the option elements listed for this drop-down list box with the following code:

<xsl:value-of select="xdExtension:PopulateDropdown(string(my:BoundField))" disable-output-escaping="yes"/>

Where my:BoundField is the same value as that of the xd:binding attribute on the select element.

Save the view .xsl file, and then close the text editor.

Try it:

Launch your modified solution by double-clicking the manifest.xsf file.

In the InfoPath editor you will see a drop-down list populated with Select... and Test.

Choose Design This Form from the Tools menu.
In the InfoPath designer you will see a red box indicating your Preserve Code Block.

You can now modify the PopulateDropdown function to process whatever information is required to populate your drop-down list. The string returned must not contain any XSL code, but only contain properly formatted HTML with option elements.

You will need to use the sSelectedValue parameter to identify which of the option elements is the currently selected option. You must make sure that, in your code, you set the selected="selected" attribute on the correct option element. Otherwise the drop-down list in the view will never show the selected value, but will instead always revert back to displaying the first option in the list.

This technique is demonstrated in my example forms: Fully Editable Drop-Down List Box and Moving Items Between List Boxes.

Posted Jul 12 2004, 12:31 PM by Greg Collins with 8 comment(s)

Filed under: Code, Lists

Remove a Print Header or Footer

To add a header or footer to your InfoPath form printout, do the following:

In the Views task pane, double-click the view for which you want to add a header or footer.
In the View Properties dialog box, select the Print Settings tab.
Click Header, or click Footer.
Construct the header or footer the way you want and then click OK.
Click OK to exit the View Properties dialog box.

That was the easy part. The hard—rather confusing—part is trying to remove the header or footer you just created. Try it:

In the Views task pane, double-click the view for which you want to remove a header or footer.
In the View Properties dialog box, select the Print Settings tab.
Click Header, or click Footer.
Press CTRL+A to select the entire text, then press DELETE.
Click OK.
Now click header, or click footer, again—the text was not deleted! What happened?

You can do this over and over and nothing will change. I'm sure this was just an oversight on the part of the developers. A bug that was not caught. So what can be done?

The answer is simple—instead of pressing DELETE, press SPACE, then click OK. Now when you go back to look, the header or footer will have been successfully deleted. InfoPath recognized that you had unprintable text and so it defaulted back to removing the header or footer.

Posted Jul 09 2004, 10:56 AM by Greg Collins with 1 comment(s)

Filed under: Printing, Header, Footer

Identify the Current Table Row

If you are trying to identify the current table row so that you can make modifications to other field in that row, the safest thing to do is to make those modifications using code. This will be the fastest (performance-wise) solution. You can see how this is done by playing with my example form: Populating Table Row After Selection (Code).

But if you absolutely do not want to touch code, you can do this with Rules and a node to hold the current row position. This RowPosition node should be located in a secondary data source so as to not dilute your main DOM. The concept is simple.

Let's assume you have an XML structure, using the "my" namespace, that is organized like the following:

    People
        Person
            Name
                First
                Last
            Address
            Phone
            Email

Let's also assume that we have a secondary data source named Support that is organized like the following:

Support
RowPosition

You would create a Rule on the desired node, in this example, we'll use Phone. The Rule will set the value of the RowPosition node, in the secondary data source, to the XPath function count(XPath_To_Repeating_Row_Node) + 1. In this case the XPath would be ../preceding-sibling::my:Person. Why my:Person? Because that is the actual "row" of the table. That is the repeating node. So if we were to place the Rule on my:First, we would have to modify the function to include an additional axis specifier (i.e. another "../"). The resulting XPath would then be ../../preceding-sibling::my:Person.

This will work even when filters or conditional formatting are used to hide certain rows.

Once you have the row position saved, you can use it to get direct access to your row for making updates to other fields. You do this by modifying the XPath of each Rule that updates another field on the row. In the case of our example XML structure above, you would locate my:People/my:Person/... in the XPath and modify it to include the specified row. It would now look like: my:People/my:Person[number(xdXDocument:GetDOM("Support")/Support/RowPosition)]/... .

You must specify the XPath number() function or this technique will not work.

Posted Jul 08 2004, 11:54 AM by Greg Collins with no comments

Filed under: XPath, Rules, Repeating Tables, preceding-sibling, count, number, current

Display Multiple Fields in a Drop-Down List Box

While developing your InfoPath form, you might need to have a drop-down list box display more information from more than one field. This is actually quite simple by manually modifying your view .xsl file. In this task we will demonstrate the changes necessary to display multiple fields in a single drop-down list box.

APPROACH 1:

The first approach is the easiest. It involves manually modifying the view .xsl file and using the XPath concat() function to display the combined values of multiple fields in the drop-down list box.

If, for example, you have XSL that looks something like this:

<option>
    <xsl:attribute name="value">
        <xsl:value-of select="my:EmployeeId"/>
    </xsl:attribute>
    <xsl:if test="$val=my:EmployeeId">
        <xsl:attribute name="selected">selected</xsl:attribute>
    </xsl:if>
    <xsl:value-of select="my:LastName"/>
</option>

Modify the XSL (see the changes highlighted in red) to look something like this:

<option>
    <xsl:attribute name="value">
        <xsl:value-of select="my:EmployeeId"/>
    </xsl:attribute>
    <xsl:if test="$val=my:EmployeeId">
        <xsl:attribute name="selected">selected</xsl:attribute>
    </xsl:if>
    <xsl:value-of select="concat(my:LastName, ', ', my:FirstName, ' (', my:EmployeeId, ')')"/>
</option>

These modifications will roundtrip in the designer. This means that when you load your form template in the designer, make changes to it, and then save it, these modifications will not be lost.

APPROACH 2:

The second, and potentially more robust, approach is to populate the drop-down list box via code. This technique is demonstrated in my example form: Fully Editable Drop-Down List Box. By using code, you can completely customize your drop-down list box.

Posted Jul 08 2004, 02:33 PM by Greg Collins with 2 comment(s)

Filed under: Lists, concat()

Avoid an Endless Loop During Event Bubbling

Event bubbling means that when an event, such as the OnAfterChange event, happens on a particular data node in an XML tree, that event is passed up to the parent node, and then the grandparent node, and so on, all the way back to the root node. Thus the event "bubbles" up the tree.

Consider an XML structure like the following:

    Group1
        Node1
        Node2
            Attribute1
            Attribute2
        Node3

If all you wanted was to know whether Attribute1 had changed, you would place an OnAfterChange event handler on Attribute1. But this event would also then be passed to Node2, and then to Group1.

If however you wanted to know whether any node under Group1 had changed, you could place an OnAfterChange event handler on Group1. This is very powerful. Now you can write a single event handler to manage value changes for all of Group1's sub nodes rather than write individual event handlers on each node.

But how do you know which node the event occurred on to be able to properly respond to it? The InfoPath event object has a couple of properties that help you resolve this. They are Site and Source.

Site: The XML node that the event handler is attached to.
Source: The XML node that caused the event.

Thus if the OnAfterChange event handler were placed on Group1 and a change occurred to Attribute2, when the event handler was called, the Site property would be Group1, and the Source property would be Attribute2. You could use a switch statement on Source.nodeName to handle the event differently for each node under Group1.

But with all this power comes the danger and responsibility. A serious problem can occur if you handle the event on Group1 and then as part of handling that event you make a change to one of its child nodes, let's say, Node3. The change made to Node3 will now set off another round of OnAfterChange events, which will then bubble up to Group1, causing another change in Node3, which will then bubble up, and so on. This is known as an endless loop or recursion.

InfoPath catches endless loops--it will stop them after 16 calls to prevent the form from locking up. But that still doesn't solve your problem. You really don't want to ever get into an endless loop. So what can be done?

If you know that your form users will never modify Node3, but that only your code will be modifying it as part of the event handler, you can use the Site property of the event object to filter out any events that originated from Node3. If the user will be making changes as well, then you can set a Boolean flag in your code, identifying that it was the code, and not the user that made the change. Then when the event bubbles up and the flag is set, you simply reset the flag and do not make the change to Node3 again.

Using this technique you can effectively prevent endless loops, or recursion, during event bubbling. To see this technique demonstrated, take a look at my examples forms: Populating Table Row After Selection (Code), Fully Editable Drop-Down List Box and Accessing and Updating Repeating Table Row Cells.

Posted Jul 07 2004, 08:04 PM by Greg Collins with no comments

Filed under: Code, Events

InfoPath Dev

This Blog

Syndication

Recent Posts

Tags

Archives

Greg Collins

July 2004 - Posts