107697 - Change MAPI SendMail to comply with Message Compose changes

Status: VERIFIED FIXED

(MailNews Core :: Simple MAPI, defect, P1)

Description

[Rajiv Dayal]

There has been a design change in the Message Compose interfaces, this effects
the design of MAPISendMail and MAPISendDocument implementation. This bug is to
track these modifications for trunk landing.

Below is the mail from JF regarding these changes :

Hi Rajiv,

I  checked in this morning some major change that affect the way we manage
attachment in message compose. I have replaced the string list we were using in
nsIMsgCompFieds by an array of object of type nsIMsgAttachment. Also, I have
made some of the APIs obsolete.

Think to not use anymore:

nsIMsgCompFields::GetAttachments
nsIMsgCompFields::SetAttachments
nsIMsgCompFileds::GetTemporaryFiles
nsIMsgCompFileds::SetTemporaryFiles

instead, use the new one:

nsIMsgCompFileds::GetAttachmentsArray
nsIMsgCompFileds::AddAttachment
nsIMsgCompFileds::RemoveAttachment
nsIMsgCompFileds::RemoveAttachments

Also, I made obsolete nsIMsgComposeService::OpenComposeWindowWithValues and
nsIMsgComposeService::OpenComposeWindowWithCompFields. If I remember right, you
are not using them.

The goal of this change is to allow to specify more information about
attachment. Now you can specify the name, the url, if it's a temp file, the
content-type, etc... That should allow you to simplify your code.

Let me know if you have any question
JFD

Comment 1

[Rajiv Dayal]

Attachment: patch with changes to comply with changes in Msg Compose

Comment 2

[Rajiv Dayal]

Hi JF and Scott,
Can u please r and sr the attached patch with changes in SendMail code to comply
with the changes in Msg Compose to handle attachments using the path name and
real file name.
thanks, - Rajiv.

Comment 3

[Tiantian Kong]

Reassign to Krishna, since Rajiv is on vacation.

Comment 4

[Jean-Francois Ducarroz]

Comment on attachment 56761 [details] [diff] [review]
patch with changes to comply with changes in Msg Compose

looks good. R=ducarroz

Comment 5

[Scott MacGregor]

+                    nsAutoString realFileName ;
+                    realFileName.AssignWithConversion ((char *)
aFiles[i].lpszFileName) ;
+                    attachment->SetName(realFileName.get()) ;

can probably be expressed as 
attachment->SetName(NS_LITERAL_STRING( (char *)aFiles[i].lpszFileName).get());
which potentially saves an extra string copy.

other than that, everything looks good. 

Comment 6

[Krishna Mohan]

The NS_LITERAL_STRING mechanism doesn't work here as it is internally converted
using the standard 'L' convertion macro, wich takes a literal string and
substitutes in pre-processing phase.

Comment 7

[scottputterman]

reassigning to rdayal.

Comment 8

[Scott MacGregor]

if ns_Literal_STRING won't work, how about nsDependentString instead of
nsAutoString?

Comment 9

[Rajiv Dayal]

attachment->SetName expects a unicode string, so we need to convert the ascii
string data here to unicode string data, nsDependentString wouldnt do this for us.

Comment 10

[Scott MacGregor]

Comment on attachment 56761 [details] [diff] [review]
patch with changes to comply with changes in Msg Compose

sr=mscott

Comment 11

[Rajiv Dayal]

checked in to MAPI_NEW_DIR_TRUNK branch.

Comment 12

[Rajiv Dayal]

checked into the trunk.

Comment 13

[Trix Supremo]

verified on mozilla & netscape trunk 2002022703 builds