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