Sorry I've been out of this discussion for a couple of days, but I found a way to make this work so I've been busy coding it.

As you figured out, what I was trying to do was include both the HTML and text version in one email and let the client decide which one to display using multipart email content. Specifically, I wanted to find out how to do this using WWIPStuff, since I'm already using that to send messages now. Currently, we have a list of domains that seem to have troubles with html files (as reported by our customers), so, when my program sends the email, it checks the table of domains for the address, and if it finds it, sends the txt version, otherwise it sends the HTML version. We are also working on gathering an email type preference from our customers, so eventually, they'll tell us which version to send. In the mean time, using WWIPStuff, the following code works:

THIS CODE WAS POSTED ON THE WEST WIND WWIPSTUFF MESSAGE BOARD BY CHRIS JEFFRIES ON 1/18/01:


Here is what I've created to send what are known as multipart emails. This method takes 3 paramenters: The plain text message, the HTML version and a reference to the oIP object (because I need to change some properties). Multipart emails let the email reader decide how it should be displayed and I think that's how most folks send them out (like webvan, mp3.com, etc.)
It took the best part of a Saturday to figure out this multipart methodology as there's not much online I could find.

Please excuse the messy formatting and minimal comments, but hopefully it can be useful to someone.

Have fun,
Chris.

***************************************************
FUNCTION PrepareEmailContent
*********************************************************************
* formats email content based on HTML and/or plain text content
* and creates a multipart email
LPARAMETERS tcStdContent, tcHTMLContent, toIP

LOCAL lcMsgContent
DO CASE
CASE !EMPTY(tcStdContent) AND !EMPTY(tcHTMLContent)

lcBoundaryCode = SYS(2015)

* toIP.cContentType = [multipart/alternative; ]+CRLF+[ boundary=] + '"'+lcBoundaryCode+'"'
toIP.cContentType = [multipart/alternative; boundary=] + '"'+lcBoundaryCode+'"'

* the document preamble
lcMsgContent = "This is a multipart document. If you are reading this text, you might consider upgrading to an email reader that supports multipart messages" +CRLF+CRLF

* the plain text document
lcMsgContent = lcMsgContent + "--"+lcBoundaryCode +CRLF
lcMsgContent = lcMsgContent + "Content-type: text/plain; charset=US-ASCII"+CRLF+CRLF
lcMsgContent = lcMsgContent + Response.ExpandTemplate(tcStdContent,,.T.,.T.) + CRLF+CRLF

* the html document
lcMsgContent = lcMsgContent + "--"+lcBoundaryCode +CRLF
lcMsgContent = lcMsgContent + "Content-type: text/html"+CRLF +CRLF
lcMsgContent = lcMsgContent + MergeText(tcHTMLContent) + CRLF

* final boundary marker
lcMsgContent = lcMsgContent + "--"+lcBoundaryCode+"--" +CRLF

* =strtofile(lcMsgContent,"c:\temp\msg.txt")
RETURN lcMsgContent

CASE !EMPTY(tcHTMLContent)
toIP.cContentType='text/html'
RETURN tcHTMLContent

CASE !EMPTY(tcStdContent)
toIP.cContentType='text/plain'
lcMsgContent = Response.ExpandTemplate(tcStdContent,,.T.,.T.)
RETURN lcMsgContent
OTHERWISE
RETURN ""
ENDCASE
ENDFUNC


***************************************************



Cheers,

Rob

>RFC 2046 (http://www.ietf.org/rfc/rfc2046.txt) in section
>5.1.2 (Handling Nested Messages and Multiparts) defines how to send a message in multiple formats:
>
>" In general, user agents that compose "multipart/alternative" entities
> must place the body parts in increasing order of preference, that is,
> with the preferred format last. For fancy text, the sending user
> agent should put the plainest format first and the richest format
> last. Receiving user agents should pick and display the last format
> they are capable of displaying. In the case where one of the
> alternatives is itself of type "multipart" and contains unrecognized
> sub-parts, the user agent may choose either to show that alternative,
> an earlier alternative, or both."
>
>So I´m 100% sure it CAN be done, however you may find mail clients that do not process the message correctly. But it´s the program fault, not a message problem.