InfoPath Dev

I have searched the forums here and on Microsoft's site and have not been able to find a workable solution to my problem.

 I have an InfoPath form, designed with InfoPath 2010, that has previously been filled out using the InfoPath Filler.

 While switching it over to being a browser-based form, there is one issue that keeps arising.  When submitted from the browser to an email address, the formatting gets completely messed up.  The forms is composed using nested tables; all the columns and fields are set to fixed pixel widths, as is the page.  However, the resulting formatting in the email does not reflect this, and goes far beyond the limits.  Since I have already set all the fields and cells to fixed widths, what else can be done to remedy this?

 Thank you!!

Hi-

The typical solution to these type of formatting issues (i.e. when printing or when sending email) is to have separate sections: one section for "filling out" the form and another section for emailing.

This is discussed: http://www.infopathdev.com/forums/p/22656/78476.aspx (there may be other discussions but I find this one most useful). I employ Hilary's suggestion:

Hilary Stoupa:

InfoPath is mean like this.

What we do is have two sections in the active view (the one that we can email). We add a true / false (boolean) field named something like "isEmailing" and default it to false.

Then, in conditional formatting, hide one section if isEmailing is false, the other section if isEmailing is true. All the controls that the user fills out or should see while filling out the form go in the section that hides when isEmailing is true. All the stuff we want in the email goes in the section that hides when isEmailing is false.

Then, the rules on the email button would be:

1. Set isEmailing to true (hides the fill in section, displays the email section)
2. Submit via email
3. Set isEmailing to false (hides the email section, displays the fill in section)

Hopefully this helps!

Unfortunately, that will not help, as I just need to email the same view that the user fills out.  The formatting of the fields gets messed up, though, with the field width extending far beyond its designated width.

I have even tried rebuilding a test version of the form from scratch, utilizing one table, with no nesting, and before even inserting any fields the formatting became messed up once submitted via email.

It seems that, on top of everything else, it cannot handle merged cells?

I'm sorry, I don't know what else I could recommend. Sadly, designing a form for viewing in the browser's UI is not the same as designing the form for viewing in the email UI. That's why many people turn to having separate views (for filling out, for printing, for emailing). Anyway, let us know how things go.

Desired results have painstakingly been achieved as follows, with explanations in parentheses:

1. Ensure that the width of every field in the form is a numeric pixel width and not a percentage (reason: percentage widths will not format properly when emailed)

2. Each line of the form has to be created as a separate table (reason: when the browser form is submitted via email, it does not like merged cells and will completely mess up the formatting)

3. Any date-picker contained in the form has to be recreated separately in its own section as just the data for the email submission, using the guidelines from earlier in this conversation post (regarding section hiding and such).  This will thereby make sure that the date-picker field itself will not be part of the email submission (since the date picker field will also completely mess up the formatting)

To elaborate, in one instance I have one field that is a date picker, called "Date"; this field with title are now in their own section, which I have called "DatePicker_Section".

I have created a second section directly beneath this, containing a text field called "DateValue", in a section called "DateValue_Section".  The "DateValue" field is set as a locked Date formatted text field (and not a date picker field), with the formula set to equal the value of the "Date" field.

I then used the sections and rules outlined earlier in this handy post from Hilary Stoupa, setting it up so that the DatePicker_Section is visible when the form is being filled out, but that the DateValue_Section is visible when the form is submitted via email.

Following the many painstaking hours it took to make all these changes, my form is now properly submitting and emailing without messing up any of the formatting. :)

:D

 Thank you all for your help!