Email formatting messed up for browser-based form - InfoPath Dev
in

InfoPath Dev

Use our Google Custom Search for best site search results.

Email formatting messed up for browser-based form

Last post 06-04-2013 09:04 AM by Joy_T. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • 06-03-2013 10:58 AM

    • Joy_T
    • Not Ranked
    • Joined on 10-25-2012
    • Posts 20

    Email formatting messed up for browser-based form

    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!!

  • 06-03-2013 11:48 AM In reply to

    Re: Email formatting messed up for browser-based form

    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!

    Ernesto Machado
    Qdabra® Software/ InfoPathDev.com
    The InfoPath Experts – Streamline data gathering to turn process into knowledge.™


  • 06-03-2013 12:20 PM In reply to

    • Joy_T
    • Not Ranked
    • Joined on 10-25-2012
    • Posts 20

    Re: Email formatting messed up for browser-based form

    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?

  • 06-04-2013 05:26 AM In reply to

    Re: Email formatting messed up for browser-based form

    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.

    Ernesto Machado
    Qdabra® Software/ InfoPathDev.com
    The InfoPath Experts – Streamline data gathering to turn process into knowledge.™


  • 06-04-2013 09:04 AM In reply to

    • Joy_T
    • Not Ranked
    • Joined on 10-25-2012
    • Posts 20

    Re: Email formatting messed up for browser-based form

    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!

Page 1 of 1 (5 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.