280678 - Simple MAPI call attaches temp file instead of specified attachment filename

Status: RESOLVED DUPLICATE of bug 273849

(Thunderbird :: General, defect)

Description

[Kevin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Thunderbird 1.0

When some application sends attachments via Simple MAPI (SMPAI), they specify
the path of a temp file along with the name that the mail application should
actually use on the attachment.

Thunderbird doesn't handle this situation in all cases (it attaches with the
name of the temp file).

I believe that one of the following SMAPI functions is not being handled properly:

MAPISendDocuments
MAPISendMail

With some applications, the attachment is attached properly, and with others it
isn't, so it seems like one of the above functions is implemented properly.

The application that I know for sure can be used to recreate the problem is
SnagIt (www.snagit.com) - although any application that uses the function in
question with a temp file will cause the same behavior.

Reproducible: Always

Steps to Reproduce:
1. Install SnagIt (www.snagit.com) free trial
2. Select the "A region to File" option in the left side of the main snagit screen
3. In the right side of the screen, change the Output to be "Send Mail"
4. Click the "Capture" button
5. Choose a region of the screen
6. In the "Preview" dialog, click the Finish (Send Mail) button




Actual Results:  
TBird will open a new mail message - but note that the file extension on the
attachment is .tmp.

Expected Results:  
The extension should be PNG.

If you repeat the same operations with a different mail client (Outlook, for
example) the attachment has the correct extension (PNG).

If the problem is in the MAPISendMail implementation, TBird should be using the
value in the lpMessage->lpFiles[i].lpszFileName field as the attachment filename
instead of the lpMessage->lpFiles[i].lpszPathName field.

If the problem is in the MAPISendDocuments implementation, TBird should be using
the value obtained by splitting the lpszFileNames parameter instead of the
lpszFilePaths parameter.

Obviously, you'll still want to use the lpszPathName and lpszFilePaths values
for obtaining the content of the attachment - this bug has only to do with what
the attachment is actually named once it hits the mail message.

Comment 1

[David :Bienvenu]

*** This bug has been marked as a duplicate of 273849 ***