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!

VFP Email

Status
Not open for further replies.

quailco

Programmer
Nov 25, 2019
13
US
I have been using the code from faq184-3840 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
Screenshot_404_wpq8fp.jpg
.
Screenshot_406_ybsnpg.jpg


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.
 
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
 
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
 
...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
 
Olaf said:
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
 
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.
 
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
 
Thanks Olaf. Soundslike r saying give it up, you cant get there from here
 
You should know yourself if SSL is a prerequisite or not. See 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
 
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
 
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
 
Then use MAPI. See faq184-1769

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
 
can I use it as a part of a batch program sending notices without operator intervention
 
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
 
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
 
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
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top