Suppose you want to have the items listed in a drop-down be dependent on the selection of another drop-down (this is also known as "cascading dropdowns). If you have InfoPath Service Pack 1 installed, you could use the "Filter Data..." feature to accomplish this.
You have one drop down labeled "State:" with the names of states and another drop-down labeled "City:" which gets populated with the names of the cities for the state you selected on the previous drop down.
The city drop-down obtains its values from an xml file which might look something like this:<Cities> <City state="Washington">Redmond</City> <City state="Washington">Seattle</City> <City state="California">Los Angeles</City> <City state="Florida">Orlando</City></Cities>
File Attachment Control
Applies to: Microsoft Office InfoPath 2003 SP1
Microsoft Office InfoPath 2003 SP1 introduces a number of new controls. One of these new controls, the file attachment control, enables you to insert files which will be encoded and saved with the form. This control opens up a number of new scenarios not easily possible before SP1.
For example, let’s say that you have created a form that will be used by your sales people in the field. Typically, your sales people may track large amount of sales data in an Excel spreadsheet which includes fancy charts and pivot tables. When these sales people report their quarterly earnings, you would like them to fill out an InfoPath form so that you can gather data such as total sales per region. However, since the sales people have already gathered all the detailed sales data in an Excel spreadsheet, you don’t want them to have to reenter the data into the InfoPath form. Instead, your sales people click on a file attachment control and attach the spreadsheet containing their sales data. Later, when you are reviewing the data in the InfoPath form, you can double-click the spreadsheet file and open it in Excel in order to view the detailed sales data.
Adding a file attachment control to a form is easy. Just follow these four basic steps:
Now, when you preview the form or fill out a form based on this form template, users can attach files to your form. Also, if you open a form that has existing file attachments, you can double-click on the control to open it. When opening files that are already attached, by default, the application that is associated with that file’s extension on your system is opened in order to view the file.
For security reasons, not all types of files can be attached to a form. The last thing you want is for somebody to attach a malicious executable file that formats your hard drive. For this reason, InfoPath blocks certain file types from being attached (e.g., .exe, .com, .bat, etc.). To determine the types of files that are considered unsafe, InfoPath follows a similar model as Outlook which is documented in http://support.microsoft.com/default.aspx?scid=kb;EN-US;290497.
In addition to the list of file types blocked by default, you can further restrict the types of files you want users to attach to your form. To do so, perform the following:
Upon attaching a file, InfoPath first builds a header structure which includes information about the file being attached. The structure consists of the following:
· BYTE: Signature (based on the signature for PNG):
(decimal) 199 73 70 65(hexadecimal) C7 49 46 41 (ASCII C notation) \307 I F A
The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as a file attachment. The rest identifies the file as an InfoPath File Attachment.
· DWORD: Size of the header
· DWORD: IP Version
· DWORD: dwReserved
· DWORD: File size
· DWORD: Size of file name buffer
· File name buffer: variable size
After building the header structure described above, the header and file data are concatenated and base64 encoded. This base64 data is then stored with the XML data in the form. (More information about base64 encoding can be found here: http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html.)
If you wish to write code to work with InfoPath file attachments, the .NET framework provides a Convert class that includes methods to encode and decode base64 data (e.g., Convert.FromBase64String). These methods can be used to decode existing InfoPath file attachment data or to encode a file for storing in an InfoPath form.
When a file attachment control is inserted into an InfoPath form, the following processing instruction is inserted into the XML template for the form:
This processing-instruction is added as a convenience for InfoPath but is not meant to be a security feature. If this processing-instruction is removed, when users fill out the form, all file attachment controls will be disabled.
Looking for some of our answers to questions we get a lot? Pull up the Microsoft Office InfoPath 2003 Technical FAQ - if you don't find the answer you need in the FAQ, please ask your question on the newsgroup microsoft.public.infopath where MVPs, experienced InfoPath users, and Microsoft InfoPath team members can all help.
One question that comes up often regards a no-cost InfoPath Viewer. Here are three Q&A's in the FAQ worth pointing out:
Q. Do employees need to have InfoPath installed on their PCs in order to fill out forms created with InfoPath? Is InfoPath required for viewing or reading an InfoPath form?
A. Information workers will need to have InfoPath 2003 installed on their PCs to enter information into InfoPath forms and to take advantage of the rich client functionality such as structural editing, business-logic validation, rich-text formatting, AutoCorrect, and spell-checking. That said, you can read an InfoPath form that has been saved to .MHT in your browser or within an HTML-enabled e-mail client, as the body of your mail message. Because InfoPath generates XML belonging to any customer-defined schemas, other software could be used to reuse and display that XML document. Q. How do users fill out an InfoPath form if they do not have InfoPath?
A. In order to fill out forms created in InfoPath and to take advantage of InfoPath’s rich-client functionality, data validation and offline capabilities, users will need a copy of InfoPath installed on their workstation.
It is possible to build browser-based solutions based on InfoPath forms. For example, you can build a solution in InfoPath (building a schema and Web services) that can be used for collecting information within the firewall, then use the same schema and Web services for building an ASP.NET solution for collecting information outside the firewall. For business solutions that require a “reach” (browser-based) solution, yet still use the power of InfoPath for the parts of the process that occur within an organization (where InfoPath can easily be deployed), there are two options:
Q. Do I need to touch every desktop to deploy InfoPath? Can you host an InfoPath form in the browser?
A. In order to fill out or design an InfoPath form, InfoPath needs to be installed on the desktop. However, once you have deployed InfoPath, you can easily roll out the form templates that users need to use InfoPath. InfoPath provides transparent deployment and maintenance of solutions via a Web-like model that downloads solutions on demand. InfoPath form templates are downloaded silently and seamlessly to the client when a user clicks on a link to an InfoPath form or clicks on an InfoPath attachment.
A process to create an InfoPath Viewer experience if read-only is all you want: note that if you just want to be able to have a read-only rendering of an InfoPath form beyond what InfoPath can generate directly (save as MHT or via an email body), you should take a look at the SDK downlevel tool (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipsdk/html/ipsdkUsingTheDownLevelTool.asp ) which provides a way to modify your form XML to pull in a stylesheet to use for rendering the form when InfoPath is not on the user's machine.
What's the difference between a form and a form template?
We've had some people ask us about the difference between a form and a form template. It's easy to confuse the two--partly because people often expect them to be the same thing, and partly because of how we use the terms in InfoPath.
When you design a new form in InfoPath--say, a status report for your department to fill out, you're actually creating a form template. This is the file that defines the data structure, appearance, and behavior of the forms that your users fill out. The form template usually has an .xsn file name extension, and actually consists of several files that have been compressed into one, including one or more XML schemas, an XSLT file for each view in the form, an XML file for the default data, script files or managed code assemblies, and a form definition file (manifest.xsf), which contains information about the components of the form, including how it looks and acts, deployment settings, and data connections.
After you finish designing the form template, you can publish it so the people in your department can start filling in their status reports. As you might've guessed, each of their status reports is a form. That form is just an XML file that contains the data (and only the data) that's been entered into the form. All the other stuff that makes up the form--the graphical interface, the validation, the data connections--is provided by the form template. Which means that whenever you open a form in InfoPath, that form needs to locate and use the form template to function properly. (Otherwise, you'd just be looking at plain XML data.) To link the form to the form template, InfoPath includes a processing instruction in each form that points to the associated form template. (For those of you wondering how this works when you're offline: When you use a form, the form template is cached on your computer.)
One last note, for the pathologically curious: For a variety reasons, we often use the term "form" to mean both forms and form templates. For example, there's a Fill Out a Form command and a Design a Form command on the File menu. We tried using "form template" whenever discussing the .xsn file, but we discovered that the term actually confused more people than it helped. It turns out that people were much more likely to think of what they were designing as a form, instead of a form template. This stems most likely from paper forms, which are always called "forms," whether they're being designed, printed, or filled out. Also, in some cases, it was hard to draw a distinction between forms and form templates: Should the Form Options dialog box be titled Form Template Options, because you access it in design mode, or Form Options, because the choices affect how the forms will look? Finally, a hard and fast rule can make things pretty awkward: Instead of the Design This Form command, for example, we'd have Design the Form Template Associated With This Form.
TRICK: Localized form in a single view
Need the same form in many languages? Here’s a trick that’s easier than multiple views.
By taking advantage of new SP1 features, there’s a simple way to create a multi-language view without duplicating bindings.
I have used a secondary data source with read-only borderless fields as labels for the view. This secondary data source is populated by an XML File Data Connection that grabs a file in the LabelsLanguage form library. This form lib populates a drop-dom, changes of this update the aux-dom and refresh the view.
There are 2 buttons for adding new languages and editing the current labels of the form. These pop up a second solution. To add a new language, just fill out the form and submit. Look at one of the existing languages for examples. If you see a typo in your language, feel free to correct it and save.
To work with button labels, manually update the view using xsl:value-of elements. Otherwise, use the workaround that I have in the screenshot.
Here’s a sample of what it might look like:
How to Enqueue Submits While Offline
User fills out forms for a particular form template while the laptop is disconnected from the network. Upon reconnection, seamlessly syncrhonize the offline forms to a Windows SharePoint Services form library.
Using OnSubmitRequest, you can have the code save to the offline folder depending on if we're offline or not, as in the following code, which is written in C# using our Visual Studio .NET Toolkit. You will also need to add a project reference to System.Xml.dll and the using System.XML; directive to your form code.
public void OnSubmitRequest(DocReturnEvent e)
Then, if you've been offline for a while and a number of files have built up, you can run the following jscript to invoke InfoPath externally and force a submit looping through the files, as below:
This tip applies to form designers who want to change the default print margin on a form using InfoPath 2003 since the Service Pack 1 release allows designers to change these properties in design mode from the View Properties dialog.
So, if you do not have the Service Pack 1 installed you can still accomplish this by following these steps:
marginUnitsType="in" leftMargin="0.25" topMargin="0.5" rightMargin="0.25" bottomMargin="0.5">
Notes: marginUnitsType can contain either in or cm. The rest of the margins are interpreted based on those unit types.
Question: How do I store the result of an InfoPath expression box?
Answer: with InfoPath 2003 SP1 you can use the new calculations feature. With InfoPath 2003, you can write script.
The expression box control is display only, so whatever expression you end up concocting to render on the screen is neither stored in the XML nor accessible for manipulating elsewhere. You might want this expression value to be stored in the XML, especially if you want to promote this value into a SharePoint form column.
In InfoPath SP1, rather than using an expression box, you can set the default value for a field element to be a calculated value. If the field is in the view, bring up the property dialog for the control associated with the field. If the field isn't in the view, you can go to the data source and bring up the properties for the field there. Note the fx button next to the default value. Click that to bring up a dialog for creating a calculation. This expression will be recalculated as needed and stored in the field.
To do the same thing in script, download the InfoPath SDK and look into the calculations sample. Go to this page for more information: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipsdk/html/ipsdkAboutTheCalcForm.asp (along with a discussion of the script).
Do you know about the InfoPath 2003 SP1 Preview release? There are actually two free downloads available:
Anyone can download and install this version of InfoPath and use it until it expires.
When the Office System 2003 SP1 is released (mid-2004), InfoPath will be updated to have many new features, in addition to performance improvements and bug fixes (and if you just want the performance improvements and bug fixes, the new features can be turned off). The SP1 is completely backwards compatible with InfoPath 2003.
This preview gives you a chance to try out an initial version of the SP1 bits now so that you can learn the new features and plan for the SP1 deployment within your company.
The SP1 release is very important in that we were able to address customer wishes. Give it a try! We're certainly excited about it and will be posting about InfoPath SP1 here often (and we'll make it clear when a post is SP1 specific).
TRICK: Changing the Depth of Recurring Fields
You can use the following script for promotion and demotion of recurring nodes in single depth recurrences. (This does not work in the case of a*/b/a*…). To work in your code, simply change the names of the parameters at the top and attach this code to events in your form code.
SP1 Feature Usage
The following form code is written in JScript.
Improved InfoPath Form Look and Feel
Apples to: Microsoft Office InfoPath 2003 and Microsoft Office InfoPath 2003 SP1
Looking for simple ways to jazz up your form layout?
Using tables, inline images, background colors, and conditional visibility, I created a pretty simple look and feel that groups parts of the UI together that goes a little beyond just borders.
I started by drawing a rounded rectangle in mspaint, then I cut it into smaller images and added it to a table. For the vertical part which grows, I didn’t use an image, I instead colored the background the same as the image. Otherwise I couldn’t get it to grow when nested repeating elements would resize. I removed all borders, padding, and other spacing to get everything to fit together.
For the repeating section, I used conditional visibility on section with two separate images. I had to use the following expression to get count and position for repeating sections:
// count //position
count(../../my:SummaryItem) != count(../preceding-sibling::node()[local-name() = "SummaryItem"]) + 1
With InfoPath 2003 SP1, there is a new schema for the form definition (.xsf) file, to match the features added to InfoPath.
There will be a documented roll-out of this schema, along with other InfoPath technical information, when the SP1 is officially released, but for those wanting to get a hold of the raw XSD file now, you can download the following:
Disclaimer: as this schema is the InfoPath 2003 SP1 Preview schema, it is not guaranteed to be final, and might change between now and the official release of InfoPath 2003 SP1.
Welcome to the InfoPath team blog here at http://blogs.msdn.com/infopath/ !
The InfoPath Team is looking forward to posting a variety of topics for our InfoPath users, including:
We're super-excited about InfoPath and look forward to helping our customers realize the most they can out of our new Office System 2003 application.
Please leave some feedback if there are areas you'd like to see us cover (and please remember the community support via the microsoft.public.infopath newsgroup!).
Why Smart Clients? was posted yesterday and provides a nice perspective of the benefits of having such a smart client like InfoPath.
In the feedback to "The InfoPath 2003 SP1 Preview", Laurent Kempé writes "I downloaded since a while, really cool, except that I can't attach the debugger."
Here's a work around to consider:
One of the common problems that prevents the debugger to attach is the existence of a .NET Framework newer than 1.1, for example the Whidbey Preview. InfoPath host will use the latest runtime but VS.NET 2003 can’t debug on it. One workaround against this problem is to enforce loading version 1.1 of the CLR runtime. This can be done by creating an InfoPath.exe.config file in the setup directory and specifying there the supported runtime version, something like:
<supportedRuntime version=”v1.1.4322” />
Here's a form sample for the article Code sample to change depth of recurring fields that let's you play with the promotion / demotion:
(This requires InfoPath 2003 SP1 ; to try the form, you'll need to open it in the designer and either republish it or just run Preview.)