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.
Close the form.
Are you sure?
Do you want to save the form?
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.