Outlook 2000 Message stuck in Outbox

[John Erickson]

Hi,

I'm developing an Add-in which works fine for Outlook 2003 and 2007. I'm
trying to get it to also work for Outlook 2000, but I have one problem. I am
autogenerating a message to be sent for some of the messages that I receive.
In Outlook 2003 & 2007, this generated message gets sent fine, but in Outlook
2000 it gets stuck in the Outbox and Outlook won't send the message. If I
double click the message in Outlook's Outbox and then click send, it sends
the message fine and the message gets deleted as I planned. FWIW I'm doing
all the message creation work in MAPI in a seperate thread that my add-in
sends messages to and not in the Outlook object model to avoid the
restrictions that generate possible virus warning messages. After I build the
message and set all it's properties I am calling IMessage::SubmitMessage(0)
and that seems to be all it takes for 2003 & 2007. I've looked at the message
that gets stuck in the Outbox using MFCMapi to inspect the message properties
and everything looks fine to me. I'm at a loss to explain why it's not being
sent. Have you heard of this before? Is there some property I'm not setting
or a call I'm not making that OL2000 requires?

John

 

[Dmitry Streblechenko]

Is Outlook 2000 installed in the IMO mode (which breaks Extended MAPI) or
C/W?

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-

 

[John Erickson]

It's IMO, but I know that all of the MAPI calls I'm making work well (with
the exception of this SubmitMessage call), so I don't think it's broken. Even
the SubmitMessage call succeeds with S_OK. It just doesn't send the message.
When you say it breaks Extended MAPI, what exactly do you mean?

 

[John Erickson]

I did a futher study of the differences in the properties of the message that
is stuck in the Outbox vs the message after double clicking it and hitting
send. (Fortunately it doesn't send right away and I could close Outlook 2000
and use MFCMapi to look at the properties.) The one after hitting send has
the following differences:

PR_CLIENT_SUBMIT_TIME exists,
PR_MESSAGE_DELIVERY_TIME exists,
PR_MESSAGE_FLAGS has an added bit (MSGFLAG_SUBMIT),
PR_MESSAGE_SIZE increased by 69,
PR_SENTMAIL_ENTRYID exists,
PR_SUBMIT_FLAGS exists,
PR_ACCESS looses the MAPI_ACCESS_MODIFY bit
PR_ACCESS_LEVEL changes from 1 to 0,
PR_LAST_MODIFICATION_TIME changes
named properties 0x8552, 0x8554, and 0x8583 are added.

It looks suspiciously like the SubmitMessage call is only saving the message
and not actually submitting it to be sent. Is there an additional call I need
to make for Outlook 2000?

John

 

[John Erickson]

I reconfigured it to be C/W instead of IMO and I am seeing the exact same
behavior. Another thing I have noticed now is that once I have Done 1 or more
SubmitMessage calls, Outlook will not terminate. Instead it hangs and I have
to Stop debugging to get it to shutdown all the way. After discovering this I
reviewed all my COM object references during the SubmitMessage process and I
don't see anyplace where I am not releasing a reference when I should be.
It's like Outlook itself is hung up in the SubmitMessage process even though
it returned S_OK to me. I just tried adding the FORCE_SUBMIT option to the
SubmitMessage call and that solved part of my problem. The message now gets
sent. However, I still have the termination problem if I have done 1 or more
SubmitMessage calls.

John

 

[Dmitry Streblechenko]

After calling SubmitMessage, you must immediatley release all references to
that message - it now belongs to the spooler.
Calling SubmitMessage (or any other method) after you have alreday called
SubmitMessage is a bad idea.
Are you sure all the recipients are resolved?

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-

 

[John Erickson]

In the course of converting all my MAPI code to Ansi instead of Unicode the
termination problem went away. I retested on OL2007 and Ansi seems to work
fine there too, so I guess I'll stick with Ansi. I was setting it up to
attempt Unicode calls first and if the calls failed with CdoE_BAD_CHARWIDTH
or CdoE_NOT_FOUND, then I would attempt the call with Ansi. Now I've reversed
that and I attempt Ansi first and things seem to work much better for OL2000.
Thanks for the tips.

John