July, 2006

 

 

Another post covers the InfoPath integration with Document Information Panels and Workflows, which shows how important InfoPath dev skills are to the entire Office stack.

 

On a completely unrelated note, the recent heat wave seems to have made it to Redmond, where we're in the 90's today. Yowsers!

 

- Ned

Program Manager

 

 

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…

 

 

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

 

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:

 

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.

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.

In code you can check the condition and add elements to the Errors Collection as necessary.

 

- Alex Weinstein
Program Manager

InfoPath 2007 introduces a new control, the multi-select list box, for cases when you want to allow users to select one or more items from the list of options. This list of options may be static, or may come from a data source. For example, you may use a multi-select list box to let the user pick the cities affected by the marketing campaign:

 

You may also allow users to specify items not on the list by going to Multi-Select List Box Properties, and setting the option to allow users to enter custom values:

 

Multi-select list box stores data in a repeating field. Every time a user checks an option, a new instance of the repeating field is added; every time an option is unchecked, a field is deleted. This is just like the Bulleted List control.

 

Let's analyze the data source at design time, and what goes into the XML when the form is filled out:

 

Form Design	Form Filling
Data Source Pane	User Input	Persisted XML
		<my:campaign>      <my:city>Chicago</my:city>      <my:city>New York</my:city>      <my:city>Boston</my:city> </my:campaign>

  

To specify which (if any) items should be checked in the multi-select list box by default, click Default Values on the Tools menu. Using the marketing campaign example, if you don't want any option to be selected by default, uncheck the only "city" item:

 

 

When you do this, you may see a design-time message that the "Control is bound to a missing field or group". You can safely ignore this message in this case since the point is to not have any checked by default.

 

If, instead, you want several options to be checked by default, right-click on the city item, then click "Add another city below", and specify default values for both cities:

 

 

Multi-select list boxes are supported only in InfoPath 2007 client.

 

- Alex Weinstein
Program Manager

Since I realize not everyone has installed the Beta yet (you can do it!), I figure it's time for a trick everyone can play with, even those still using InfoPath 2003.

 

You may want to do this if you have a form where you know everyone's going to fill out at least five rows, or maybe some people will even print our your form before typing in their answers (I never!). You might even want to have five rows exactly, and then disable adding or deleting rows (in Repeating Table properties), but still use a repeating table to get the data structure you want.

 

Regardless of your scenario, here's how to do it:

 

 

You can even specify different values for the columns of each row using the bottom of that dialog. And of course this works for any repeating item in your data source, not just those bound to repeating tables.

 

Save yourself a few clicks by typing the "Insert" key instead of using the menu. Each time you type "insert" it will add another row. Those two clicks per row can really add up when you have a lot of rows! If you type it a few too many times, you can also use the "Delete" key to remove the offending rows. 

 

As usual, if you've got your own tips in this area, or a cool reason to use this trick, please leave us a comment for the team to see and the community to gain.

 

Enjoy,

ned

One of the reasons we started this team blog was to get your comments (spurred by our tips and tricks), so it's exciting to see more folks chime in. Let me just take a moment to fan the flames…

 

We're always open to feature requests to help us plan for future versions. And we're also interesting in blog post suggestions, which we'll try to post on quickly. If you have kudos, well of course they're always welcome. So leave a comment to let us know what you're thinking!

 

If you need help solving a specific question, you're better off in the newsgroups, where both the product team and InfoPath MVPs are on watch and where there's a large archive of other like-minded questions. For more general issues or something you suspect is a bug, check out the support center. And for common tasks and basic overviews Office Online is your best bet.

 

Thanks!

- Ned

 

 

	InfoPath 2003	InfoPath 2007 Beta
No Visual Studio	Microsoft Script Editor (MSE)	Microsoft Script Editor (MSE) OR Visual Studio Tools for Applications (VSTA)
VS .NET 2003	InfoPath 2003 Toolkit for Visual Studio .NET	Not supported (use MSE or VSTA, above)
VS 2005	InfoPath 2003 Toolkit for Visual Studio 2005	Visual Studio 2005 Tools for Office (InfoPath 2007 Support) (related post)

 

Note that both Microsoft Script Editor (MSE) and Visual Studio Tools for Applications (VSTA) come with InfoPath 2007 Beta, so you can open them from the Tools | Programming menu. If you don't see the one you want, change the language in Tools | Form Options. If it gives you an error that it's not installed, here's how to install them:

 

 

Happy code writing!

- Ned

This is the final segment of my three part series. In the first part of this series I introduced the concepts involved in three tier authentication. Then I covered single sign-on with some code. Now we'll go one step further…

 

 

InfoPath Forms Services includes a Web service proxy which can forward SOAP requests to a Web service to enable authorization for a data query.  The premise is simple – the proxy runs under an account that is trusted by the Web service.   The Web service authenticates the trusted account.  In addition, the proxy sends the identity of the calling user in the SOAP header using a WS-Security UsernameToken.  The Web service can then use the provided identity to determine what data to return from the query.

Setting up a connection to use the proxy is straightforward.  First of all, the connection has to use settings from a UDC file on the server.   The UseFormsServiceProxy attribute on the ServiceUrl element in the UDC file determines whether InfoPath and Forms Services will forward the Web service request using the proxy:

 

Everything else on this end is automatic.  It's a little more interesting on the Web service end.

It's tempting to consider using the WSE 2.0 library to consume the UsernameToken from the Web service request.  WSE 2.0 has methods to automatically consume WS-Security headers.  However, the default behavior of WSE 2.0 is to attempt to logon using the credentials in the UsernameToken.  It is possible to override the default behavior by specifying an alternate UsernameTokenHandler.  However, there is a more straightforward approach.

First, declare an array of SoapUnknownHeader at class scope in your service:

 

 

Then declare a SoapHeader attribute for the web method:

 

public ExpenseInfo[] GetMyExpenses()

 

 

if (null != unknownHeaders && unknownHeaders.Length > 0)

{

     // look for a userNameToken and return the username if present

 

In the example, I'm searching for a Username element anywhere in the headers.  To be more precise, the UserName is within a UsernameToken element, which is in turn under a Security header in the WS-Security namespace.  The entire SOAP header sent by the proxy looks like this:

 

In order to use the identity to retrieve data, I use it as part of the query against my database.  Here's the entire Webmethod. The code assumes that you have an Expense database with a table called Expenses, and that one column of the table, called Employee, contains the Windows username of the employee who filed the expense.