I asked this question before about Outlook 2000 and I've now discovered more
about it and I've also repro'ed the problem on Outlook 2007. What I
discovered is that if I make a call to Outlook::_Explorer->get_Selection
during the OnExplorerEvent for a SelectionChange() when my current selection
is a message in the outbox, that message becomes permanently stuck in the
outbox and will not be sent unless I pull it up in an inspector and hit send.
I'm accessing the current selection to pull some properties out of it to see
if it's a message I want to do something with, but I've commented out all my
get property code and discovered that just making the get_Selection call is
all that is needed to make this happen. It's easy enough to test this by
turning off the tools->options->Mail Setup->Send immediately when connected.
That flag causes messages to wait in the outbox until send/receive is hit.

I have a work around for it, but I don't like my work-around and I'm seeking
a better work-around. My work-around entails continuing to open the message
so that I can pull properties out of it and pulling the parent entry id out
of it first so that I can tell if it's a message sitting in the outbox. If
it's in the outbox, then before releasing the opened message I call submit
again. This work-around works, but it causes some undesireable effects.
Submitting the messages again triggers the ExplorerEvent SelectionChange()
event to happen again which sort of puts me in a loop because I then have to
open it again to see if it's in the outbox and re-submit it again.
Fortunately part of what I'm doing is happening in a different thread which
yields enough time for the message to eventually get sent when I hit
send/receive, but I get this wait cursor/normal cursor swapping thing
happening which doesn't look good. Plus I eat up a lot of processor time in
the eternal loop.

So, my question to you is... Is there another work-around I can use to fix
this? Perhaps instead of resubmitting it I simply need to change a message
flag or something? There must be something I can do besides re-Submit()ing it
that won't cause the SelectionChange event to trigger again and put me in a
loop.

John

Never mind. I found a new work-around that works great. I now use
Outlook::_Explorer->get_CurrentFolder to determine if the current folder is
the Outbox and if it is I leave the current selection alone. Sorry for the
interruption.

John

"John Erickson" wrote:

> I asked this question before about Outlook 2000 and I've now discovered more
> about it and I've also repro'ed the problem on Outlook 2007. What I
> discovered is that if I make a call to Outlook::_Explorer->get_Selection
> during the OnExplorerEvent for a SelectionChange() when my current selection
> is a message in the outbox, that message becomes permanently stuck in the
> outbox and will not be sent unless I pull it up in an inspector and hit send.
> I'm accessing the current selection to pull some properties out of it to see
> if it's a message I want to do something with, but I've commented out all my
> get property code and discovered that just making the get_Selection call is
> all that is needed to make this happen. It's easy enough to test this by
> turning off the tools->options->Mail Setup->Send immediately when connected.
> That flag causes messages to wait in the outbox until send/receive is hit.
>
> I have a work around for it, but I don't like my work-around and I'm seeking
> a better work-around. My work-around entails continuing to open the message
> so that I can pull properties out of it and pulling the parent entry id out
> of it first so that I can tell if it's a message sitting in the outbox. If
> it's in the outbox, then before releasing the opened message I call submit
> again. This work-around works, but it causes some undesireable effects.
> Submitting the messages again triggers the ExplorerEvent SelectionChange()
> event to happen again which sort of puts me in a loop because I then have to
> open it again to see if it's in the outbox and re-submit it again.
> Fortunately part of what I'm doing is happening in a different thread which
> yields enough time for the message to eventually get sent when I hit
> send/receive, but I get this wait cursor/normal cursor swapping thing
> happening which doesn't look good. Plus I eat up a lot of processor time in
> the eternal loop.
>
> So, my question to you is... Is there another work-around I can use to fix
> this? Perhaps instead of resubmitting it I simply need to change a message
> flag or something? There must be something I can do besides re-Submit()ing it
> that won't cause the SelectionChange event to trigger again and put me in a
> loop.
>
> John