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

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

"Ken Slovak - [MVP - Outlook]" wrote:

> Does it work better if you save the new copied item before calling Reply on
> it?
>
> --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Author: Professional Programming Outlook 2007.
> Reminder Manager, Extended Reminders, Attachment Options.
> http://www.slovaktech.com/products.htm
>
>
> "Womble" <Womble.DeleteThis@discussions.microsoft.com> wrote in message
> news:544A949A-B5F0-49EA-84EC-DF38618938FB@microsoft.com...
> > 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.
>
>

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Womble" <Womble.TakeThisOut@discussions.microsoft.com> wrote in message
news:01AC813E-780D-4A71-8A7F-34064E2915E7@microsoft.com...
> Saving it first i.e. NewMail.Save makes no difference. I still get the
> same
> error.

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]" wrote:

> 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.
>
> --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Author: Professional Programming Outlook 2007.
> Reminder Manager, Extended Reminders, Attachment Options.
> http://www.slovaktech.com/products.htm
>
>
> "Womble" <Womble RemoveThis @discussions.microsoft.com> wrote in message
> news:01AC813E-780D-4A71-8A7F-34064E2915E7@microsoft.com...
> > Saving it first i.e. NewMail.Save makes no difference. I still get the
> > same
> > error.
>
>

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Womble" <Womble DeleteThis @discussions.microsoft.com> wrote in message
news:BC2A59D2-206C-48E9-A968-BA2ADC9DF831@microsoft.com...
> 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.

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]" wrote:

> Umm, don't open the atachment?
>
> 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.
>
> --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Author: Professional Programming Outlook 2007.
> Reminder Manager, Extended Reminders, Attachment Options.
> http://www.slovaktech.com/products.htm
>
>
> "Womble" <Womble.RemoveThis@discussions.microsoft.com> wrote in message
> news:BC2A59D2-206C-48E9-A968-BA2ADC9DF831@microsoft.com...
> > 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.
>
>

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Womble" <Womble.RemoveThis@discussions.microsoft.com> wrote in message
news:D34C3FA7-4F42-40A0-80CB-7ECA36F42A49@microsoft.com...
> 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.