May, 2006

 

 

 

 

 

 

If you're writing script anyway, or if you need to check this value as part of a bigger algorithm and don't want to persist the username anywhere in the form, then you can also access this value in script:

 

 

Of course, you can also use this in C# or Visual Basic, but you could always use System.Environment.UserName, so that's nothing new.

 

For security reasons, either approach will make your form require domain trust, so you'll need to publish the form to a shared location (like Windows SharePoint Services) for the function to work.

 

Enjoy!

-ned

Although the primary purpose of Visual Studio 2005 Tools for Office (InfoPath 2007 Support) is to add C# and Visual Basic code to your InfoPath form template, you can still take advantage of hosting InfoPath inside Visual Studio to design forms that don't have any code.

 

When you create a new InfoPath form template project in Visual Studio, by default, it will be created with code enabled.  To obtain a form without code, you need to explicitly remove the code from the form by using the remove code button in the programming tab of the form options dialog.

 

 

After clicking on this button, you might be confused to see that the code file is still present in the project.  Don’t worry about this.  When you build the project, the hosted designer will not add the output assemblies to the form template.

 

After a new project is created, the “enabled” attribute of the “managedCode” element in the manifest.xsf defaults to “yes”.  Clicking the remove code button sets this attribute to “no”.

 

 

This attribute is set back to “yes” when you insert an event handler using the hosted InfoPath designer.

 

After a success build, the output assemblies will only be included with the form template when this attribute is set to yes.

 

- Gary

Software Development Engineer

I'm super excited to announce Microsoft Office InfoPath 2007 Beta and Microsoft Office Forms Server 2007 Beta for browser-enabled forms, so you can install both of them today.

 

 

 

After registering you'll get to select which products you want, which should include:

 

All are available in English, French, Spanish, German, and Japanese, so tell your friends!

 

If you're a regular Visual Studio code-junkie, then download the Visual Studio 2005 Tools for the Microsoft Office System (InfoPath 2007 update), which is also included in the Visual Studio Tools for Office "v3" June Community Technology Preview.

 

Woohoo!

- Ned and the whole exuberant InfoPath team

As part of getting everyone up to speed on Office 2007, and in preparation for the imminent release of the Beta, we've just posted some "Partner technical readiness training" videos.

 

It includes a great one on using InfoPath in Outlook, so I thought I'd call it out:

 

You can check out all the videos here:

 

Enjoy!

-ned

My forms have a bad habit of accumulating more and more rules as I add more and more functionality over time, so I came up with a set of guidelines to keep those rules clean and orderly.

 

 

 

Good names will summarize their conditions/actions in a more friendly way: eg "Submit using multiple data connections", or "Cancel query if expenses too high".

 

If more than one action has the same condition, put them together so you can edit the condition only once. Otherwise, put each action in its own rule, so you can easily reorder them independently.

 

If there's a case where you don't want to run any of your rules, add a rule that checks that case. It doesn't need to have any actions, just check the box to stop processing rules and put the rule before any of the other rules that would also check that case. For example, if you want to skip some submit logic if the expenses in the form are less than 100, put that condition in its own rule before your submit logic, and just have it stop the rules.

 

Dialog messages are great for tracing your rules at runtime, but are usually jarring while filling out the form. If you have a condition message to show, use conditional formatting instead to hide/show a section/expression-box with the message. You can even make the message dynamic by having the expression box look up a value in the data source and setting that value from the rule.

 

The “Set a field’s value” action is best for values that only need to be set/copied once, or for values that are conditional. For values that need to update every time another field changes unconditionally, best to use a calculated default value. Good examples for rules:

 

If you've got your own best practices we'd love to hear them! Post a comment to share your insights with the whole community.

 

- Ned

InfoPath forms are all about being dynamic, so it's important that the sections in your form grow and shrink appropriately. For example, if someone deletes an optional section from inside another section, the outer section should shrink accordingly.

 

 

Of course, sections will grow/shrink by default after you insert them, but InfoPath will change it to a fixed size if you resize the section, since we don't want to disobey your command to be a specific size. So in the example above, the outer section will stay the same size even when the Notes section isn't there -- it will just have a bunch of white space in its place.

 

If you resized a section by accident and want to return it to the default, just open its properties, switch to the "Size" tab, and type auto for the height. Now it will only be as big as it needs to be and never bigger.

 

- Ned

 

One way is to right-click the field or group and select "Move Up" or "Move Down". This is great for novices because it's discoverable, but it's a painful number of clicks if you're an expert who has to move a lot of fields in many forms.

 

 

 

 

Hope that helps!

ned

In my last post I covered how to make Wizard-like forms. This time I want to talk about another common practice for organizing all the fields in a form: grouping each set of fields onto a "tab" so the user can switch between the sets in whichever order they wish. While wizards are useful in forms with a clear flow, tabs are useful when the same form will be updated multiple times in different places.

 

In Windows XP, tabs look like this (this screenshot's taken from InfoPath's View Properties dialog):

 

 

InfoPath doesn't have a built-in Tab Control, but it's easy enough to build one using tables, buttons, and views, so let's do it!

 

Here's what to build:

 

For example:

 

 

Then when the user clicks "Details" they switch views to see this:

 

 

 

If the tabs above aren't pretty enough for your form, add some images inside a few more table cells around each button to provide rounded corners and other visual effects. It's more work, and requires some image editing, but with a little elbow grease you could get something as schmancy as this:

 

 

 

Enjoy,

Ned