Why use a loop? You might end up in that loop forever.
MailItem has a number of events it exposes: Send, Close, Open, etc. A
MailItem is displayed in an Inspector, which also exposed events such as
Activate and Close. In general one handles events in Outlook code to do what
you want.
If you instantiate a MailItem object declared WithEvents (I'm assuming here
you're using VBA or a variant of VB) you can handle any events on that item.
That would let you detect MailItem.Send or .Close. The Write event would
fire if the user saved the item.
Every item is displayed in an Inspector. oItem.GetInspector gets you that
Inspector object, which if declared WithEvents would let you handle
Inspector.Close, which might fire under certain circumstances where
Item.Close won't fire.
I'd spend some time reviewing the code samples at www.outloocode.com to see
how Outlook item and Inspector events are handled. You'll find code there
for whatever language you're coding in.

Signature
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm
> Hello !
>
[quoted text clipped - 21 lines]
>
> Thanks
Michel S. - 23 Dec 2006 16:15 GMT
Thanks for your answer Ken.
I'm considering a loop because I want the Excel macro execution to be
suspended until the user has finished the e-mail processing (send or
close). Is this what the Modal parameter of the .Display method is
for ? Are there side effects to this to be aware of ?
I wend to the site you mentioned (I guess you meant www.outlookcode.com
?) and found some interesting samples.
I made a small class module in excel where I create and display a mail
item and containing various event sinking routines containing only code
to get a trace of the events sequence while I edit, save, close or send
the mail item; for now these routines are all like the following one :
Private Sub objMailItem_Send(Cancel AS Boolean)
Debug.Print "MailItem send"
End Sub
From a standard module, I create an instance of this class, and call
its "Display" method. Once the execution is finished, I can see the
Open/Send/Close and the Open/Close sequences in the immediate window
depending on what I did with the message. So far so good. :-)
For some strange reason, I found that few test messages I sent were
stored in the "Inbox" instead of the "Outbox". Since they are
datestamped at the beginning of my tests, I guess it is due to some
objects correctly not closed or set to null during the early steps of
programming. I'll post back if I find this to be false.
So far, I only had to resort to the MailItem object. What are the
circumstances you say the Inspector would be used for ? How an Item
close event wont fire but the Inspector's will ?
Thanks again !
Ken Slovak - [MVP - Outlook] a présenté l'énoncé suivant :
> Why use a loop? You might end up in that loop forever.
>
[quoted text clipped - 50 lines]
>>
>> Thanks
Ken Slovak - [MVP - Outlook] - 26 Dec 2006 15:06 GMT
Sorry, that was a typo with www.outlookcode.com.
The problem I see with a loop is that it may become infinite. Then the code
is essentially locking up your computer. If I was to use a loop I'd
condition it with a flag that was set before entering the loop and cleared
when any of the relevant events was fired. That way at least you'd know when
to terminate the loop.
In some versions of Outlook you can get an Inspector.Close and not an
Item.Close depending on whether WordMail is being used and if Send is fired.
As I recall there are a couple of other obscure cases but I haven't played
with that for a long time since my template code always handles both Close
events, so I haven't needed to determine the cases in a while. Your mileage
may vary.

Signature
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm
> Thanks for your answer Ken.
>
[quoted text clipped - 31 lines]
>
> Thanks again !
Michel S. - 26 Dec 2006 20:22 GMT
Thanks again for your reply.
I realize that I used loop instead of
loop-waiting-only-for-a-window-to-be-closed, which is another way of
describing a modal window. ;o)
What are your thoughts about using " objMailItem.Display Modal:=True "
in an Excel class module and then simply return whether the MailItem
Send event fired or not ?
Just to recall the context: I only want to build OL mail items from
inside an Excel application, display each one to the user and record
whether or not he actually sent it as the mail window is closed..
Since I'm mostly an Excel and Access developer, I'm not very familiar
with Outlook gotchas, but having to implement and use the Item's
Inspector object only for that purpose seems a little overkill to me.
Am I missing something ? Any gotchas ?
Thanks
Ken Slovak - [MVP - Outlook] a pensé très fort :
> Sorry, that was a typo with www.outlookcode.com.
>
[quoted text clipped - 18 lines]
> Reminder Manager, Extended Reminders, Attachment Options
> http://www.slovaktech.com/products.htm
Ken Slovak - [MVP - Outlook] - 26 Dec 2006 22:02 GMT
If you display an Outlook item modally the modality is only in relation to
Outlook. I don't think it necessarily would be modal to Excel or Excel code.
Displaying an Outlook item modally can also cause "ghost" Inspectors. When
the user closes the window an empty window remains until the user closes
that.
I don't know that using best practices with handling Outlook events is
necessarily overkill, but that's up to you.

Signature
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm
> Thanks again for your reply.
>
[quoted text clipped - 17 lines]
>
> Thanks