1

Closed

Sender name/email not available in message properties in MAPI when sending an email

description

Hi Team,

I am developing an application that will tell attachment in email using MAPI.

1) When I send an email, the sender name is coming up in some systems and there is a problem in others. I have implemented the technique that is provided in MFCMAPI ( I have used AdviseSink Notifications ).

2) Where sender name is not coming, its giving "0x8004010f <Bad Ptr>" values. When I can retrive PR_MESSAGE_DELIVERY_TIME, then there shouldn't be any problem to retrieve sender name of an email. And I can't even check for bad pointer.

3) 0x800A001E gives sender name of email when the mailbox is connected to Exchange and 0x800D001E gives sender name of email when the mailbox is connected to Internet email. Kindly name these properties. And, even these properties give bad pointer values when AdviseSink Notifications are implemented.

file attachments

Closed Jun 16 at 2:40 PM by sgriffin

comments

sgriffin wrote Jun 13 at 2:38 PM

2 - 8004010f is MAPI_E_NOT_FOUND - whatever property you asked for wasn't there.
3 - You should look at the named prop names.

How is any of this a bug in MFCMAPI?

talib2608 wrote Jun 14 at 7:51 AM

This is not a bug in MFCMAPI, but it is a bug in MAPI subsystem. Where to post about the bugs of MAPI subsystem. There are many.

2) There is inconsistency here: We look for property names for most of the properties and named prop name for some. Also, while retrieving property we can't send parameter as PidLidInternetAccountName. We have to send as 0x800A001E or 0x800D001E.

talib2608 wrote Jun 14 at 9:14 AM

If MAPI_E_NOT_FOUND is returned when the property is not available would be good. "0x8004010f <Bad Ptr>" as a returned value would confuse some developers

sgriffin wrote Jun 16 at 2:40 PM

0x8004010f is the same thing as MAPI_E_NOT_FOUND. It's not a bad pointer. You're not checking the type of the returned property. It was PT_ERROR, which means you should be looking at the .err member and interpreting it as an error code.

There's no inconsistency. You need to read about named properties:
http://msdn.microsoft.com/en-us/library/office/cc765864(v=office.15).aspx

I'm closing this bug. Please don't add further to it. If you want to discuss something, post on the discussions tab.

talib2608 wrote Jun 18 at 10:37 AM

Why don't you just return the macro 'PT_ERROR' when you have defined it? In other cases it returns as 'PT_ERROR' and not "0x8004010f <Bad Ptr>". This was so simple and it is taking you so much time.

PR_SENT_REPRESENTING_NAME and PR_SENT_REPRESENTING_EMAIL_ADDRESS still not coming when sent an email. PR_MESSAGE_DELIVERY_TIME comes up. PR_SENT_REPRESENTING_NAME and PR_SENT_REPRESENTING_EMAIL_ADDRESS comes up only when sent using public folder.

talib2608 wrote Jun 18 at 10:38 AM

.

talib2608 wrote Jun 18 at 10:40 AM

.

sgriffin wrote Jun 18 at 2:26 PM

Your attachments illustrate the difference between regular properties and named properties. In attachmant 1.pn, where you wrote "no property names", those were named properties (easily identified by the IDs greater than 0x8000). So there is no PR_* macro associated with that value (can't be, since it's not constant), and the Named prop name has the name I looked up with GetNamesFromIDs.

In attachment 2, you highlighted the Named prop name column for properties under 0x8000, which are not named properties. So they wouldn't have names to look up.

You really need to go read the documentation I linked. It explains all this.

As for your comment about PT_ERROR - are you even talking about MFCMAPI? I don't understand the context of the complaint.