Link to home
Start Free TrialLog in
Avatar of TomPreen
TomPreen

asked on

MSMAPI email

I have a VFP 9 exe application with an msmapi activex control.

When the user sends an email it fails intermittently with a message that the target email is not in the address book, even though the target email address is recorded in outlook.
Avatar of Olaf Doschke
Olaf Doschke
Flag of Germany image

Could you show your code?

A target mail address doesn't need to be in the address book, unless you only specify the name of the recipient, which outlook then looks up in an address book, but maybe not in the one you think of. If you specify the mail address, Outlook should not need to do so.

Bye, Olaf.
more concrete: instead of using RecipDisplayName and ResolveName() rather use RecipAddress

Bye, Olaf.
Avatar of TomPreen
TomPreen

ASKER

I am specifying the email address the problem is it fails to send and errors with a message that the email address does not exist.

Are you saying that if I do not code ResolvName() then it will send regardless of an entry in the address book?
If you will use CDO mail (described e.g. here: http://fox.wikis.com/wc.dll?Wiki~CdoEmail or here: http://www.sweetpotatosoftware.com/spsblog/2005/07/12/EmailAndVFPPart1cCDOSYS.aspx) you'll never have problems with Outlook Addressbook...

CDO mail is easy and reliable.
an email it fails intermittently
errors with a message that the email address does not exist.


Are you 100% certain that you are always attempting a legitimate email address?

I have clients who repeatedly make typo mistakes entering their client's email addresses or their client themselves provide invalid email address syntax (such as leave off the .COM, put spaces into the address, use commas instead of periods, etc.) and it will result in a similar email error message from Outlook when encountered.

Good Luck
Again: Could you show your code?
Or do you not have it, are you just the user of an EXE?

I only guess you are the developer and have found the code in Craig S. Boyd's Blog article about Mailing with VFP via MAPI. That code uses the name resolving feature of MAPI. If your software does that, you rather specify the normal name of a person, eg "firstname lastname" and name resolving finds the mail adress. Specifying a mail address in the first place then is wrong, as a mail adress isn't the display name of a address book entry.

In development terms: You need to call the ResolveName() method of the MAPI.Message object, if Outlook (or other MAPI mail clients) should resolve the mail adress from the name you specify in RecipDisplayName, but only then. And specifying something unknonw as display name would cause the error you experience.

If you specify RecipAddress instead of RecipDisplayName, you don't have to resolve the mail adress, as you specify it in the first place, RecipAddress is the propery of a MAPI Message, which is set by ResolveName(), but if you specify it, you don't depend on name resolving. This is what most users of a mail software or a mail feature of an application do, entering the mail address. But that is not what works with Craig's sample code.

If you're the programmer:
You have a ton of different possibilities to send mails in a VFP application. As you want to support Outlook, I'd rather automate Outlook.Application than anything else.

MAPI is only good, to support many MAPI compliant mail clients, but it's much easier to send mails via SMTP directly. Using CDO would go in that direction.

Google VFP Mail and you'll find many possible solutions. This won't help you of course, if you're just a user, but then you're halfways wrong here in this section, we only can make guesses about what your EXE really does and why it errors with that message.

The only thing you can try is enter the display name into the application, the name Outlook displays for the recipient, rather than the mail address.

Bye, Olaf.
Here is the code.

Tcto is a fixed entry from a parameter table. The same email address is always used.

LPARAMETERS tcTo, tcSubject, tcBody, tfile
LOCAL llreturn

Thisformset.FrmEmail.TMCSESSION.SignOn()
IF Thisformset.FrmEmail.TMCsession.SessionID > 0
  TRY
     WITH THisformset.FrmEmail.TMCSEND
      .Sessionid = Thisformset.FrmEmail.TMCsession.SessionID
      .Compose()
      .RecipDisplayName = tcTo
      .RecipType = 1
      .ResolveName()
      .MsgSubject = tcSubject
      .MsgNoteText = tcBody
      .AttachmentIndex = .AttachmentCount
      .AttachmentName = "sltran.csv"
      .AttachmentPosition = .AttachmentIndex
      .AttachmentPathName = tfile
      .SEND(.T.) && send in .T. to not send email automatically but instead see it in outlook
      llreturn = .t.
    ENDWITH
    Thisformset.FrmEmail.TMCSession.Signoff()
   
   
    CATCH TO oerr
    llreturn = .f.
    =MESSAGEBOX("Error No "+STR(oerr.errorno,4,0)+" "+oerr.message)
   
   ENDTRY
   return llreturn

ELSE
 =MESSAGEBOX("Cannot access mailbox")
ENDIF  
RETURN llreturn
Well, yes, that's a shortened version of what you find at http://www.sweetpotatosoftware.com/SPSBlog/PermaLink,guid,8f569366-c76a-4873-9029-f31c07cf125e.aspx

Your error says the  .ResolveName() method fails finding the recipient you set via tcTo, so double check your value, you may also need to login to a certain user account instead of the default.

How about rather using http://www.sweetpotatosoftware.com/SPSBlog/PermaLink,guid,fb9e9267-3642-4176-94ea-9239691b61fa.aspx

Bye, Olaf.
I am not the end user. This code is part of an application that sends information to the target email once a month so I do not have control over the parameter setting for tcto but the client assures me that it is a valid email address they use regularly.

Normally for automated email I use SMTP where the server is held in a parameter and the email client is bypassed but this would not work on their system as email is routed through yahoo.

Having looked at the MSDN description for resolvename() I can see why failure is possible so I will recode to use RecipAddress for target email.
ASKER CERTIFIED SOLUTION
Avatar of Olaf Doschke
Olaf Doschke
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial