×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

VFP Email

VFP Email

VFP Email

(OP)
I have been using the code from FAQ184-3840: How to send email using SMTP and no third party OCX? as a example with just a few chgs tailoring it to my data. I get 2 errors as shown in the screenshots below. Anyone have any suggestions on how to proceed .


The 2nd SS shows DATA error in case it isnt clear. It is not obvious to me what that means but my guess is that the parameter iding the email didnt get passed properly.

RE: VFP Email

The message "Must specify additional parameters" has got nothing to do with email or SMTP. It simply means that, in the command you are using to call the Sendmail procedure, you are not passing the correct number of parameters. You are passing more parameters than are listed in the LPARAMETERS statement in Sendmail.

Just to be clear, you need to pass seven parameters - no more - just like in the example in the FAQ.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: VFP Email

(OP)
Thanks Mike

RE: VFP Email

Just a comment:

The first time I crossed that error message I also understood the inverse. As you specify parameters in the call that sounds like you have too few parameters in the call. That can actually never be the case, as VFP has no concept of mandatory parameters in user-defined functions, you can always pass in fewer parameters than a function accepts.

The message should be: Too many parameters passed in.

The message actually addresses the function/procedure/method definition. The code could take in more parameters if LPARAMETERS would be extended. But it's the rarest case the calls are correct and the function defines too few parameters. So the perspective of that error message is wrong.

It could happen, that you change a function to take fewer parameters and then need to change all calls of that function to adapt to the consolidated parameterization. And therefore that's even rarely done, it's an incompatible change.

It's also no good idea to add dummy parameters to any (L)PARAMETERS so you get no errors when a call has too many parameters. That is an error and should be detected and so you don't program defensive against it. It's just an unfortunate case of VFPs dynamic nature that does not already throw an error at compilation about too many parameters in the call.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

...and I guess the problem you had with the second error was just a side effect of calling with too many parameters, the extra parameter likely changed the correct position of another parameter.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

Quote (Olaf)

I also understood the inverse. As you specify parameters in the call that sounds like you have too few parameters in the call. That can actually never be the case
...
The message should be: Too many parameters passed in.

That's right. I had to think twice to convince myself that too many parameters were being passed rather than too few. You have to realise that the message is triggered by the incorrect number of parameters in the LPARAMETERS statement, even though the actual error occurs in the call (in this case).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: VFP Email

(OP)
I corrected the params error but the second problem persists. The routine connects with the srver but apparently does not like something about the msg.

RE: VFP Email

That was just a yes/no question. Everybody can grab code the code from there or here.

I think since the last time someone actually used that a lot happened. For example, authentication toward mail servers via SSL secured connections. And that's not covered.

See, that's the better thing in automating a client, you don't need to care for the connection to the mail server, you don't even need to ask users for any credentials.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

(OP)
Thanks Olaf. Soundslike r saying give it up, you cant get there from here

RE: VFP Email

You should know yourself if SSL is a prerequisite or not. See https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_...
Port 25 would be for unencrypted SMTP, 143 for IMAP and 993 and 995 for the secure variants of them, that require TLS/SSL.

If you insist on needing no third party component, no mail client you can use via MAPI and want to do everything on the low level of the Winsock control, you need to implement the necessary steps to establish a secure connection yourself. I would not know how to, and I am not eager to go that low level for independence, I would rather use anything else like CDO or MAPI.

Of you just want to send mail in any way, there are tons of ways you can do it.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

(OP)
thanks I dont think my knowledge of the steps to create an email is adequate. So I either have to improve my knowledge or find a new path :)

Do you have an opinion of this CDO method from the Fox Wiki explained in this link
http://fox.wikis.com/wc.dll?Wiki~CdoEmail

RE: VFP Email

If you have problems with CDO.Message, that's usually caused by CDO.Configuration not being configured to anything. Do you have any mail client installed?

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

(OP)
Yes I us3e thunderbird on my desk top

RE: VFP Email

Then use MAPI. See FAQ184-1769: How to send e-mail using MAPI session

Maybe in shortest, without desiging a form using the MAPI Session and Messsages OCXes:

CODE

oSession = CreateObject("msmapi.mapisession")
oSession.SignOn()
oMessage = CreateObject("msmapi.mapimessages")
oMessage.SessionID = oSession.SessionID
oMessage.Compose()
oMessage.RecipAddress ="recipient@example.com"
oMessage.MsgSubject = "Test Mail"
oMessage.MsgNoteText ="Test Text"
oMessage.Send(1)
oSession.SignOff() 

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

(OP)
can I use it as a part of a batch program sending notices without operator intervention

RE: VFP Email

Does this code cause any interaction for you? I don't think so. And do you know what a FOR loop is? Or SCAN...ENDSCAN? Or a DO WHILE loop? Any such structure always allows executing something repeatedly "in a batch".

Or in short: Yes.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

(OP)
lol been writing dbase then fox then VFP apps for 50 yrs. So ya I can handle most anything but this email was my first like that.
Thanks Olaf

RE: VFP Email

Well, quailco.

All I know of you is what you wrote here. If you know fox for so long, you could have answered your last question yourself. It made the impression you're a beginner not knowing anything about programming. Any code can be done in a batch once it's without any interaction, can't it?

Just an obvious hint: You don't need to create the two MAPI COM objects for each mail, the core part is from compose() to send(1) and only that would need to be in a loop.

And then if you want to distribute that look into redsit.txt in HOME() to learn what you can redistribute and see it mentions MSMAPI32.MSM for distributing the MAPI OCXes. It's not just the msmapi32.ocx.

There are further ways, Craig Boyd once wrote 10 ways to send mail, and as you see there is more than one FAQ on how to send mail. What you found only has Winsock dependency and you would also need to ensure you distribute that (see MSWINSCK.MSM in redist.txt), it's only more common to be existing. Well, it was more common at the time that code was written. The main point though is, it assumes you only need simple authentication to the mail server and only implements the least few SMTP commands to send a mail and is still so much more code. The most sample code about sending mail you find does not do all that, as it's tedious and subject to change. A MAPI complient mail client will a) make the mail server communication for you and b) already be configured about mailserver, port, authentication, etc. You don't need to ask your users any security relevant informations, their mail client knows.

To send mail this way also is within VFPs own samples, by the way:

CODE

Cd Addbs(Home())+"samples/solution/ole"
Modify Form sendmail.scx 

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

It doesn't work with my mail server requiring STARTTLS authentication. That's not covered by this code.

>ERROR [250-PIPELINING250-8BITMIME250-STARTTLS250 AUTH LOGIN PLAIN] -> ERR09

Looking for anything more to setup up in the VFP_Winsock_Send_Mail class about authentication the way it's necessary for secure connections, I don't find anything. Today mail servers requiring secure login are the norm and Atout Fox will need to add this feature to make it usable again.

If you want to depend on the least MAPI is already a very fine solution, works for this case. CDO is too, but Thunderbird doesn't seem to set up CDO.Configuration. That's not impossible, but you need to go into the details about how that's done.

Besides that, this VFPwwinsock code is the least dependent on anything, but for the price of going very low level. The version history shows that from version 1.05 onwards it's not even using the Winsock.OCX anymore, it uses the WS2_32.DLL. So not only no external components, no OCX. This is an OS DLL. The Winsock.OCX is from MS, too, but not standard anymore. Still, it would only be complete, if it supports advanced authentication, Koen, therefore I wouldn't recommend VFPwinsock.

MAPI will be as safe as your mail client allows, and Thunderbird allows connections to be made via SSL/TLS or STARTTLS. So in this way, MAPI automatically updates with the capabilities of mail clients. As long as you have one and as long as MAPI remains a Windows OS standard for addressing mail clients. I don't even know a mail client that isn't supporting MAPI unless you'd roll your own mail client for example with that code. And to be clear: Using MAPI means you only communicate with a mail client in a standard way MS has foreseen for that, the mail client then puts your sent mail into it's sent items as one benefit and cares for the mail server, not only about connection but retries, etc.

I'm all eyes and ears, how you'd solve that, Koen, it would be okay to have that. No matter if as an external add-on establishing an SSL tunnel first, or as an extension of VFPwinsock. For several reasons:

1. Atout Fox is an active community and so that code is maintained. Unlike Craig Boyd, whos series of sending mail in different ways isn't even complete in his blog.
2. It allows sending HTML Mail, which simple MAPI does not. Some clients can be used in the tricky way to leave the text body empty and add an HTML attachment, which is then made the HTML mail body, but Thunderbird does not do that.
3. The ExtendedMAPI.FLL that exists from Craig Boyd has comments stating it's only working when the user is in the admin group of a system. So while it also allows HTML emails, that's an obvious minus.
4. It could be the basis of usage on servers, where installation of mail clients is not the norm and unless you're running on the server that also runs Exchange, CDO also isn't an option.

There is another alternative you also find googling: Using blat with VFP. That also has all the features and all it adds to the distribution process is that single DLL. It makes use of the same C runtime the OS uses, still, just one version covers all OSes from 2000 up to Win10. So using and distributing that doesn't need any advanced merge module installation step or registering.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

Olaf,

Quote (Olaf)

It doesn't work

Please clarify "It"

Rgds,

Koen

RE: VFP Email

(OP)
Olaf, Just so I get it right rather than searching and maybe not getting the right code; where is the VFPwwinsock code referred to as the best MAPI solution?
Jim

RE: VFP Email

(OP)
Koen, if you discover it does work or needs only something minor, do let me know and thanks for helping.
Jim

RE: VFP Email

VFPWinsock isn't a MAPI solution. Winsock does circumvent using any mail client and goes directly to a mail server. But it can't handle mail servers requiring SSL connections.

MAPI works, has a merge module you can distribute (if you're interested in distributing your software at all and don't just program for yourself). It only can't send HTML mails (or that depends on the mail client, but your Thunderbird is an example of NOT supporting the workaround).

ExtendedMAPI can do HTML mails, but isn't recommendable. At least not the FLL.

More details are in what I already wrote. If you don't understand something, perhaps point out what exactly puzzles you.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

Also, quailco,

if you ask for my recommendation: I'd use the MAPI code (using msmapi.mapisession and msmapi.mapimessages or see sendmail.scx). That's why I brought it up. And for a solution needing no mail client installed use blat.dll or (perhaps easier to program) the blat.exe.

A pure VFP solution shouldn't be your major concern, just something redistributable and usable for all OSes. Any solution not needing a mail client will require you to ask for email server details and credentials. That's something many users working in a company just get set up and don't even know, so a MAPI solution has the advantage of not needing that. Any computer without an Internet connection wouldn't work for you anyway and show me a workstation or personal computer desktop without a mail client.

If your software is underlying privacy regulations using MAPI is also fortunate, as it moves part of the responsibility into the mail client, your application doesn't need to know and handle any secrets securely. Plus that client documents what you sent, so users have their control about that in the usual environment, their mail software. Any software circumventing that does not only need to secure sensitive information and keep it safe but also does not comply with legal aspects of business communications that requires the transparency of keeping track of both received and sent communication, for example. I also don't know what applies to you here.

If you only need this to send an email about the success of a daily scheduled task, as I once did, then this is internal use and does not fall under such legislations. And then you may even set up your own local mail server only for internal use and set it to simple authentication and configure it yourself for your software. For sake of simplicity, I'm a big fan of MAPI and otherwise, the simplicity Outlooks automation COM server offers, if you program for a company using that.

Mail clients can defend themselves from being automated by MAPI on one side (that's positive) and can be configured to allow usage. From the top of my head Outlook has options in its trust center to allow your software to automate it. So anything is done in consent. and you, for example, also don't need anything notorious.

There are always not just the technical aspects. You didn't tell anything about your needs and what you prefer or need.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

(OP)

Quote (Olaf, Just so I get it right rather than searching and maybe not getting the right code; where is the VFPwwinsock code referred to as the best MAPI solution?)


Let me restate that.
Just so I get it right rather than searching and maybe not getting the right code; where is the MAPI code referred to as the best MAPI solution

RE: VFP Email

I gave one MAPI solution. You can learn more from the FAQ I referenced already: FAQ184-1769: How to send e-mail using MAPI session

Have you read that? Have you understood the captions saying what each code snipped does? The snippets are not alternatives you pick from that all do the same thing, they are for different aspects.

So there is no best. Different aspects need different code. I also just gave you the basics for sending a mail, see above.

Quote (quailco)

where is the VFPwwinsock code referred to as the best MAPI solution?
You're still not getting that VFPWinsock is not at all using MAPI, it's using Winsock, which to mapi is the difference of starting at atoms instead of a meal you just need to warm up. Which should also explain why any winsock example has so much more code.

I don't know how I can make that any clearer.

The line oMessage.Send(1) does trigger everything VFPWinsock does, making a connection and sending the mail. And it does more: Putting it in the outbox of the mail client, so it cares for all the parts you therefore don't need to think about at all, including not only the socket handling and connecting via SSL but also in case internet is down or the mail server is down repeating that, just like mail clients as Thunderburd do when a mail is in the outbox, until it's sent and put into sent items. And you don't need to care for all that.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: VFP Email

Hi Qualico,

here is the link to the website of Francis, author of VFPWinsock : Link
Regards,
Koen

RE: VFP Email

(OP)
Thanks Koen

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close