>Hi,
>
>Exist a method for send a report in e-mail with VFP ?

You have to create the report as a File in a readable format - either ASCII, or some common document format such as a PDF or WOrd document, and then mail the attachment to the recipient. There are several email classes in the Files section that allow you to create emails within VFP and attach a file to it, such as Nigel Coates' MAPIMAIL class. It requires that each target system have a MAPI-compliant email program installed along with the OS-version-specific MAPI support files; most email clients such as Outlook, Outlook Express, Netscape Communicator and the like are MAPI compliant, a few aren't, so you need to be sure that MAPI is usable before trying to send through MAPI.

SMTP is another protocol which can be used to send internet-based email; Rick Strahl's wwIPStuff contains SMTP support. It does not interact with the email log of the user's email program, so tracking email sent with SMTP needs to be handled by your app. SMTP works as long as the user has an Internet connection with an SMTP server willing to accept SMTP messages from the user (most ISPs tell you the name of your SMTP server when you set up the internet connection; some firewalls will interfere with sending SMTP out directly; they either need to be reconfigured, or will provide it's own SMTP server that you reference instead of the ISP's server.

Obviously, if the email system doesn't work with the Internet, and isn't MAPI-compliant, other methods will be needed. One commercial product, IDSMail, support a number of non-MAPI mail products as well as general MAPI software, and interfaces with VFP well using an ActiveX control. It's simple to use and gives the programmer a standard interface to access email regardless of the actual email system running at the workstation.

An alternative is to choose one particular product and support that, making it a required system component. I find that Outlook offers considerable advantages for mail and schedule management which most other products won't match. When I can specify the actual software for the client's site, I tend to pick Outlook (along with the rest of the MS Office suite) so that I can exploit the specific interface it delivers. For example, I can create both emails and faxes with Outlook; as long as the email and fax setup was properly configured within Outlook, I needn't worry about how it works, just how to tell Outlook what has to be done. The downside here is that everyone must have Outlook installed for things to work, as well as the rest of Office, in order to have the features available in my app. My general thinking on this assumes that the cost of the functionality that requires the user to purchase a copy of Office Standard edition or better for each system is much lower than the cost of writing equivalent procedures to either duplicate the functions inside of Office, or to generalize the current product-specific routines to handle other products, usually complicating the code and losing some product-specific features.

>
>Scuse me for my bad English! :-))
>
>
>Thank in advance
>
>Regards
>Annibale