OL2003 & VB6:- "Could not send the message"

[Womble]

I've got some code that I'm changing the reply method for.

In order to ensure the original message is not changed, I'm creating a copy
of the item but with the reply method I get a "Could not send the message" -
any thoughts. An extract from the relevent section:-

Set CurrMail = application.ActiveInspector.CurrentItem

Set NewMail = CurrMail.Copy()

Set NewFwd = NewMail.Reply

NewFwd.Display

I know it's the .Reply because if I replace NewMail.Reply with
Currmail.reply it works perfectly.

 

[Ken Slovak - [MVP - Outlook]]

Does it work better if you save the new copied item before calling Reply on
it?

 

[Womble]

Saving it first i.e. NewMail.Save makes no difference. I still get the same
error.

 

[Ken Slovak - [MVP - Outlook]]

Then I'm inclined to think it's a timing problem. If putting a DoEvents in
between saving the item and calling Reply doesn't do the trick then after
saving get NewItem.EntryID, release all references to the objects and get a
new object using the saved EntryID and NameSpace.GetItemFromID() and see if
that does the trick.

 

[Womble]

Ken,

Thanks for that, the DoEvents didn't work. But the GetItemFromID() approach
did.

Unfortnatly, that moved me onto another hurdle.

The reason I'm copying is that I'm modifying the reply method, and wanted to
ensure that the original item was not affected. And this works fine as I
expected - except when I have an open attachment. The Currmail.Copy code
gives me a "An attachment to this message may be currently open in another
program......" message.

If I click YES to continue, the codes works fine. If NO, then NewMail is
empty and the code falls over with Object Expected.

Any thoughts, as to how I can work around this.

 

[Ken Slovak - [MVP - Outlook]]

Umm, don't open the attachment?

Or handle the AttachmentRead() event on that item. That will tell you the
attachment was opened, use that to get the hWnd of the attachment window
using a Win32 API call such as FindWindow(), then send or post a WM_CLOSE
message to that window when you want to close the attachment window.

 

[Womble]

Unfortunatlly asking the users to close the attachment before clicking the
new button isn't really an option - similar with getting the code to close
the attachment prior to the copy.

Because I'm trying to code my own reply behaviour within an attatchment i.e.
I want to Create a "Reply with History" button while leaving the default
behaviour of Outlook to be Reply without history. Therefore when I had
issues around the behviour of Outlook when changing the properties of the
email, I felt that copying the item was the best approach.

Anu thoughts as to how Outlook manage it, because it's own reply button
doesn't prompt about an item being open when I use it's button.

 

[Ken Slovak - [MVP - Outlook]]

I have no idea how Outlook does things like that internally. For a reply the
attachments on the original message are always stripped out anyway though,
so that is likely the answer. You might want to look at saving any
attachments that you want on the reply to a temp folder in the file system,
then adding them to the reply message rather than making a copy of the
original message.