Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Send Email with Attachment

Status
Not open for further replies.

abbasaif

ISP
Oct 8, 2018
89
AE
Hi

Is it possible to send attachment (if converted into PDF) and send to a fixed email address?

Our outdoor sales person are using tablets by doing RDP but they are not able to print directly on WiFi Printer.
They save the output into PDF (Using FoxyPreviewer.App). And, then they send it to their own email address from where they can print it.

What I want is, the sales person enter the Invoice No. it should be converted into PDF and then it should send the email.

If the output is saved into PDF without going into Preview and then using the saving command to convert it. I use like that

Report form locfile('\Reports\SdPrint.Frx') to File tmpSd.Pdf

Then as an attachment (tmpSd.PDF) it should go to a particular email address.

I hope I tried my best to convey!

Regards

Abbasaif

 
Abbasaif,
Yes it is possible and easy to do. Which procedure do you use to send E-mails from VFP?
Koen
 
Code:
Report form locfile('\Reports\SdPrint.Frx') to File tmpSd.Pdf
IIRC foxypreviewer documentation tells you to use OBJECT TYPE 10 clause to print to PDF files on top of TO FILE ...PDF.

Anyway, that's just how you handle printing to PDF and a separate question.

Since you use Foxypreviewer you should know that additional to PDF printing it also allows to mail the resulting document: page 32ff.

So that may be one solution to you. It's not what I'd prefer, as I still see mailing an attachment as side task of a mailing routine and not vice versa adding a message to a PDF attachment.

As Koen alrady said it'll depend on what you're using for mailing, but attachemtns are easy enough:

wwIPStuff: Setting a cAttachements property to a list of file names
CDO.Message: Call AddAttachment() method for each attachment
MAPI: See faq184-1769 "Sending a message with an attachement"

Bye, Olaf.

Olaf Doschke Software Engineering
 
Hi Abbasaif,

1) You can use MAPI:

Code:
#DEFINE mapToList  1
#DEFINE mapCcList  2
#DEFINE mapBccList 3

FUNCTION MapiMail( emailStr, subjectStr, textStr, docName, fileName )
	LOCAL MAPISession
	LOCAL MAPIMessages
	
	MAPISession = CREATEOBJECT( "MSMAPI.MAPISession" )
	
	WITH MAPISession
		.LogonUI      = .T.
		.DownloadMail = .F.
		.SignOn
	ENDWITH
	
	MAPIMessages = CREATEOBJECT( "MSMAPI.MAPIMessages" )
	
	WITH MAPIMessages
		.SessionID = MAPISession.SessionID
		.Compose				&& create new E-Mail
		
		IF NOT EMPTY( emailStr )
			.RecipIndex         = .RecipCount
			.RecipDisplayName   = emailStr
			.RecipAddress       = emailStr
			.RecipType          = mapToList
		ENDIF
		
		.MsgSubject         = subjectStr
		.MsgNoteText        = textStr		&& MUST NOT be empty !!!
		
	        .AttachmentName     = docName
		.AttachmentPathName = fileName
		
		.Send( .T. )				&& show new E-Mail
	ENDWITH
	
	WITH MAPISession
		.SignOff
	ENDWITH
	
	RELEASE MAPIMessages
	RELEASE MAPISession
ENDFUNC

2) or You can use VBA:

Code:
#DEFINE olByReference  4 
#DEFINE olByValue      1 
#DEFINE olEmbeddeditem 5 
#DEFINE olOLE          6 

FUNCTION VBAMail( emailStr, subjectStr, textStr, docName, fileName )
	LOCAL outlookObj
	LOCAL itemObj

	outlookObj = CREATEOBJECT( "Outlook.Application" )
	
	itemObj = outlookObj.CreateItem( 0 )	&& create new E-Mail
	
	WITH itemObj
		.To      = emailStr
		.Subject = subjectStr
		.Body    = textStr
		
		.Attachments.Add( fileName, olByValue, 1, docName )
		
		.Display			&& show new E-Mail
	ENDWITH
	
	RELEASE itemObj
	RELEASE outlookObj
ENDFUNC

Regards, Stefan
 
Abbasaif, I see you are using LOCFILE() to allow the user to pick the FRX file that generates the PDF. That looks suspicious. The FRX is part of your application. Your program code should know where it is located. Asking the user to locate it is not only a waste of time, but is an open door to errors and security risks. The location of the file should all be handled in your code.

I know this does not answer your question, but it is something you should keep in mind.

MIke

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
I wouldn't mind that, Mike,

because you find LOCFILE() used that way in several public projects and sample code like VFPEncryption/VFPCompression using SET LIBRARY TO LOCGILE() and also FoxyPreviewer DO LOCFILE("FoxyPreviewer.App"). So it even has become a usage pattern for this otherwise rarely used function. It has a nice benefit of a memory effect, once you needed to manually locate the FLL or APP file VFP remembers its location during the current VFP session.

Yes, there is one step better, that can be done in several ways from using the environment manager to writing a project hook that establishes SET PATH/PROCEDURE/CLASSSLIB when you modify a project to a simpler PRG making all these necessary steps to simply use a prg, library, fll or also a report.

There are advantages using some of these mechanisms, but since there are many and you can't know how a developer organizes his setup of VFP, the LOCFILE is something that you can provide as compazible with any developers strategy and leave it to him to first run other steps so the LOCFILE portion actually becomes optional. But even then it never harms, it never takes any action about PATH or the default directory or anything else and it does not need you to put this into some given folder of a standard project folder structure. So it's pretty mass compatible.

Bye, Olaf.


Olaf Doschke Software Engineering
 
But,Olaf, what if the user doesn't know what he is supposed to be looking for? Wouldn't recognise the file even if he did find it? Doesn't even know what an XRF is? I suggest it is putting too much responsibility on the user. Not to mention the security aspect. If the user has the ability to tell the application what report file to use, how do we know that a knowledgeable user won't substitute his own report containing malicious code?

In fact, I agree with everything you said, but only in the context of the development environment. But Abbasaif's app is used by sales people, not developers.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Mike,

the end user will not be confronted with this, it's designed for the developer to have it easy to test code even componentwise without needing to load an initialize a fullblown framework, I know some that load quite a long time.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Hi,

Thanks for the reply! I will check all these tonight or may be tomorrow morning. And, will get back to you with the outcome.

Regards

Abbasaif
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top