File Attachments

At first glance, it seems like InfoPath really did something right with the file attachment control. When dropped into a repeating table, this dynamic way to embed content into your form blows the old HTML file input field out of the water. Not only does it nicely display the name, size, and description of the file, but it also sticks the associated application's icon in each row. And beyond aesthetics, InfoPath pops up a warning message if a large file is attached, and allows you to get into the properties and disallow certain potentially harmful extensions from ever getting attached.

But I almost had to give up on this elegant control. Why? Formatting. I spent some time in denial when I first encountered this problem, frantically clicking my way through every conceivable property page for this control, unable to believe what I was dealing with. As with all other InfoPath controls, you can specify conditional formatting that allows certain form conditions to dictate the visibility, enablement, and font and color of your file attachments.

The problem is that the "enablement" of these controls only exists in two states: enabled, and disabled. If a file attachment is enabled, then not only can it be viewed, but it can also be deleted. Or renamed. Or reattached fifty times. If a file is disabled, then it can only sit there and look blankly back at you; disabled file attachments cannot even be opened.

As far as I was concerned, this made the control essentially useless for any form that went through a workflow. People with read-only rights to the form, for example, obviously should not be allowed to tamper with the file. However, they should be able to view it. Here is how I dealt with this problem.

1. A little background: InfoPath embeds the content of its attachments directly into the form's XML as base-64 encoded strings.  In front of each string, InfoPath creates a "header" that contains meta data about the file (name, size, etc.).
2. Create your file attachment control.  If your users can attach multiple files, insert the control into a repeating table.
3. Set the conditional formatting appropriately.  For instance, if the state of the form is "New," then give the user full control to add, change, and remove files.  Otherwise, lock it down.  Also, don't forget that whenever a file attachment control placed in a repeating table is locked, it might make sense to set the table's conditional formatting to disallow the user from creating or deleting rows.  Otherwise, it will look sloppy to have a user creating rows of empty, disabled file attachments.
4. Create a button next to the control.  Use something like "View File" for the text.  The trick here is to only have this button be visible when the attachment control is both locked and has content.  Here is what the formatting code will look like: <code here>
5. Now all we have to do is create the event handler of this button and have it open the file.  In the case of repeating controls, see the Populating Repeating Tables section to isolate each button click with the correct file attachment.  This code parses out the attachment's header in the form's XML to get the file name, and then decodes the content and shows it.  Here is the event handler: <code here>
6. Clean up: we don't have to leave files hanging around on the client machine.  If they want to the file, they can save their own copy.  Have a method that deletes the files created when viewing attachments upon closing the form.
7. A word of warning: attachments can be like tumors on your form.  Since they are embedded directly into the XML, they can make the data file quite large.  Not only will bulky files simply take longer to download and upload, but XML parsing and XSL transformations will take longer, since there is simply more information  to process.  This will dim the form's bells and whistles, and hurt the overall user experience.    

"Clean Forms"

Close the form.

Are you sure?

Yes.

Do you want to save the form?

No.

Are you sure?

Yes.

You might find yourself having conversations like this with InfoPath if you do not take the time to clean your forms. I use the word "clean" because this involves setting the "IsDirty" property of your form's XDocument object. There are several ways to do this.

The first method is to write some code. I create a handler for the OnContextChange event for almost every single InfoPath form I create. Regardless of the triviality of its function, even if I'm the only user, I do not want to waste time clicking no in endless popup boxes. Adding this one little line of code to this event handler will do most of the task:

This will essentially reset the form's IsDirty property (which is actually read only) back to false after any control looses focus. If the form is not dirty, then InfoPath won't ask you if you want to save it.

However, it is possible that the OnContextChange event won't catch every single action the user could take. For example, if they enter some text into a textbox and then immediately click the "X" in the upper right corner of the window, InfoPath will still bug you about saving your form. Furthermore, the inevitable "Form (X)" will be used in the popup window. This just looks bad, especially if you are creating forms for corporate use. No one wants to see their work referred to as "Form1!"

To completely remove this annoying occurrence, you can protect your forms. This option is found in Tools -> Form Options. Select the "Enable Protection" checkbox on the first tab, and hit OK. This should probably be a best practice for your form deployment anyway, since it disables several icons on production forms. These include Design, Save, Print, etc. (You can choose to allow some of these options to be enabled if requirements necessitate it.)

Another, simpler, method is to scatter "Close" buttons all over the form. If you could unobtrusively coordinate these with the vertical scrolling behavior and arrange the buttons so that one shows up on each "screen," the user will be enticed to click them instead of mousing all the way over to the X button.

All you have to do here is add one rule to the button. The action for this rule is called "Close the Form." Then, clear the checkbox asking if a prompt should be used, and no more perky popups will rear their ugly faces on your form.

Finally, InfoPath may also bug you about submitting your form if you have submissions enabled. This can easily be circumvented by going to Tools->Submitting Forms and disabling submission functionality. I especially like this, because it removes the "Submit" button from the InfoPath toolbar. I feel that submissions should be part of the specific form, not part of InfoPath. To then implement submissions, create a button that fires rules and code, and use the final rule to close the form. This will ensure that no popup boxes will be visible.