OL2003 & VBA : How to find if a message was actually sent or canceled

[Michel S.]

Hello !

I'm developing an Excel application.

At some point, a message is built and the result is displayed to the
user who may, after reviewing it :
- click to send the message (after editing it if required)
- decide to cancel the message by closing the message window.

This message is an Outlook.MailItem object.

After I .Display the message, I'd like to enter a loop waiting for that
message to be processed by the user and record in a variable whether he
clicked on "Send" or not.

Note that since this user may work offline, the message may not
actually be sent but sitting in the outbox instead. For the
application purpose, this situation is the same as a sent message.

Any suggestions on how to achieve this ?

And, as a side question : if the user send or close the message, what
will happen to the .MailItem object ?

Thanks

 

[Ken Slovak - [MVP - Outlook]]

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.

 

[Michel S.]

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 :

 

[Ken Slovak - [MVP - Outlook]]

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.

 

[Michel S.]

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 :

 

[Ken Slovak - [MVP - Outlook]]

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.