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" wrote in message
...
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.