Add-in problem: First email in outbox gets stuck

[TTT]

I'm having a problem with an add-in we make. When "Send immediately when connected" is unchecked, the first email sent will sit in Outbox permanently. It has a Date of None and is in bold but not italics.
Any subsequent emails will have a proper datestamp and be in italics and get sent at the appropriate time (so long as the first email is still sitting there blocked).
Why is my add-in causing this? It is only happening in Outlook 2003, 2007 works fine..
Submitted using http://www.outlookforums.com

 

[Ken Slovak - [MVP - Outlook]]

Are you releasing all references to the item once it's sent and placed by
Outlook in Outbox? Any attempts to touch an item in Outbox will result in
the condition you describe.

You can always force a send by starting a SyncObjects() method call. That
can start the normal send/receive cycle and send the item out, but if you
are messing with it in Outbox it still won't get sent.

 

[TTT]

Are you releasing all references to the item once it's sent and placed by Outlook in Outbox?

I think so. Is there a way I can tell at run time?
I certainly can't see anthing that being executed different the first time from the second, and the second time works fine.

If it's any help, the email flashes up in italics before it is imediately changed to non-italics bold.

 

[Ken Slovak - [MVP - Outlook]]

Italics means the item will be sent (it's submitted to the transport),
non-italics means it won't go out. If it starts italicized and then changes
something is messing with it. Only you could tell what's different that
first time than any other time.

You can use the Locals window to see what objects are in scope and have
values at various places in your code, but as far as making sure of
releasing objects it's more a case of seeing what's declared and making sure
each object hits a release.

One possibility is an exception causing a release line to not be executed.
Another possibility is something that only gets executed in startup,
depending on when you send the first item.

Another possibility I've seen with managed code is when an object is
released by you as opposed to when it's actually released. If you set an
object to null (Nothing in VB.NET) you are releasing your object reference.
However, it's not completely released (RCW destroyed) until sometime later
when the garbage collector runs.

If you need something to be released at a specific or determined time you
can't just wait for the GC to run, although that works fine if you don't
care exactly when the release occurs.

To make something release completely you need to check it for null, then
release it like so:

if (oFoobar != null)
{
Marshal.ReleaseComObject(oFoobar);
GC.Collect();
Marshal.WaitForPendingFinalizers();
GC.Collect();
oFoobar = null;
}

If an object might have more than one reference in its COM refcount you
could need to get the return value of the Marshal.ReleaseComObject()
function and call that method until the return is 0.

Code like that will release your object references completely. However, you
need to use that sort of code sparingly. For one thing it's a performance
hit. For another, the CLR has a habit of treating different objects that
share an RCW as one and releasing all references even if you didn't intend
that.

 

[TTT]

I think this is causing the problem


if (_explorer.Selection[1] is Outlook.MailItem)
{
try
{

foreach (Office.CommandBar bar in _commandBars)
{
if (bar.Name == "Context Menu")
{
// we found the context menu
Office.MsoBarProtection oldProtection = bar.Protection;

bar.Protection = Microsoft.Office.Core.MsoBarProtection.msoBarNoProtection;

this.AddContextMenuOptions(bar, _explorer.Selection);

bar.Protection = oldProtection;

}
}
}
catch (Exception ex)
{
EmailTRACERManager.Manager.LogError(ex.Message + " " + ex.StackTrace);
}

}

 

[TTT]

It's the if statement

if (_explorer.Selection[1] is Outlook.MailItem)

and in particular, the cast(?) to MailItem. This seems to be changing the Selection item in some way so this behaviour occurs. Is this a bug or some sort of un-named reference that needs to be nulled?.
Submitted using http://www.outlookforums.com

 

[Ken Slovak - [MVP - Outlook]]

Please leave part of the preceding thread in your posts. I don't know if
that forum sucks and doesn't leave posting quoting, or if you are purposely
deleting that, but it make it very hard to follow a thread.

What folder is the Selection in? If it's Outbox you are causing the problem.
As I said earlier in the thread you should not touch items in Outbox if you
want them to get sent. Even an access to an item will prevent the item from
sending.

 

[TTT]

Thanks Ken,

Not doing this section of code for the Outbox avoids this problem. I have a related problem I will post that my not be so simple to fix.

Hope this looks better.


[quote title=kenslovak wrote on Mon, 29 March 2010 09:15]

What folder is the Selection in? If it's Outbox you are causing the problem.
As I said earlier in the thread you should not touch items in Outbox if you
want them to get sent. Even an access to an item will prevent the item from
sending.