hiding from print-out user-defined props doesn't take effect until OL restarts

M

Mark McGinty

Greets,

I'm using RDOUserPropery.Printable property to make it so our user-def props
don't print. (Sorry if that was redundant.) It works, but not until I have
restarted Outlook. I check the item's Modified property before changing
anything and log a warning if calling save doesn't set it to False. I do
the same thing again after changing it

Does this mean I'm leaking a reference somewhere? Hmm I see that if I
unload my AddIn the properties are hidden, that would seem to pretty-well
seal the diagnosis. (Damn I hate chasing leaks.)

More observations: items my AddIn creates using RDO (from database CRM)
don't have the problem... which makes perfect sense

One other thing I just noticed: for emails only, when my AddIn gets done
with one the Print Preview menu is disabled. At the moment it is *not*
setting the Printable property on them. How could it be able to print but
not preview an item? (The code is basically the same to do either, it's
just different device context.)


TIA,
MM
 
K

Ken Slovak

So what's the question? You seem to have diagnosed one or more objects not
being released, that's something only you can track down. Since you don't
provide any information such as version, language or the code you're using
what else can anyone say?
 
M

Mark McGinty

Ken Slovak said:
So what's the question? You seem to have diagnosed one or more objects not
being released, that's something only you can track down. Since you don't
provide any information such as version, language or the code you're using
what else can anyone say?
Click to expand...

The remaining question was, why/how does the Print Preview menu, only on
email messages, get disabled?


-MM
 
M

Mark McGinty

Ken Slovak said:
If you solve the leak that should go away.
Click to expand...

That doesn't seem to be the case, the condition persists even after
restarting Outlook.

I've noticed it does not occur with plain-text messages; it does occur with
HTML messages; not sure about WordMail, haven't tested (ditto for RTF.)


-MM
 
K

Ken Slovak

I'm wondering if you're hitting any unexpected ref counts for items. This is
something I've been looking at for a while now, it seems to have started
with Outlook 2007.

The symptom is say there's a mail item called _mail. It looks like there's
only 1 instance of the item and it appears that there's only 1 reference to
it.

If you call Marshal.ReleaseComObject(_mail) in Outlook 2003 you get back a
remaining reference count as 0. So the _mail item is completely released. In
Outlook 2007 I get back a count of 16 (it could be some other number). The
item isn't actually released unless I let it go out of scope and wait for
the garbage collector to run, or I run a loop calling
Marshal.ReleaseComObject(_mail) until the int return value becomes 0.

This is the same code in Outlook 2003, 2007 and 2010. In 2003 it doesn't
matter if it's WordMail or the Outlook editor, count always goes to 0 after
the Marshal.ReleaseComObject(_mail) call. In 2007 or 2010 it doesn't unless
I run the loop and then call GC.Collect(), GC.WaitForPendingFinalizers() and
then GC.Collect() again.

I'm wondering if you're seeing something of the same sort?
 
M

Mark McGinty

Ken Slovak said:
I'm wondering if you're hitting any unexpected ref counts for items. This
is something I've been looking at for a while now, it seems to have
started with Outlook 2007.

The symptom is say there's a mail item called _mail. It looks like there's
only 1 instance of the item and it appears that there's only 1 reference
to it.

If you call Marshal.ReleaseComObject(_mail) in Outlook 2003 you get back a
remaining reference count as 0. So the _mail item is completely released.
In Outlook 2007 I get back a count of 16 (it could be some other number).
The item isn't actually released unless I let it go out of scope and wait
for the garbage collector to run, or I run a loop calling
Marshal.ReleaseComObject(_mail) until the int return value becomes 0.

This is the same code in Outlook 2003, 2007 and 2010. In 2003 it doesn't
matter if it's WordMail or the Outlook editor, count always goes to 0
after the Marshal.ReleaseComObject(_mail) call. In 2007 or 2010 it doesn't
unless I run the loop and then call GC.Collect(),
GC.WaitForPendingFinalizers() and then GC.Collect() again.

I'm wondering if you're seeing something of the same sort?
Click to expand...

This is VB6 code, we started the port to .net last month, but had to put out
some fires. In researching my options for the port (still a little on the
fence, but leaning more toward shared AddIn than VSTO) I read about the
reference leak problem with multi-level object references... inopportune
timing, because to me something like Item.UserProperties.Add() is an
intuitive construct. Anyway, I'm pretty sure there was at least some of it
that was affecting my code, I was seeing occasional "can't save, do you want
to save a copy..." prompts that were confusing, especially for inherently
read-only items like inbox emails. I resolved them, though how much via
explicit object resolution I'm uncertain.

Anyway, before I lose sight of it... how does any/all of this have to do
with Outlook deciding to gray the Print Preview menu, but not the Print
menu? Clearly the item is printable, why does it care whether it's
rendering to a display device context (DC) versus a printer DC? Previewing
should be slightly less complicated than printing, one less device
dependency. It makes no sense to me.

It's not a big deal, I have PDFMachine, so I don't have to waste any
paper...

That it doesn't happen with plain-text items would seem to reinforce the
premise that leaked references shouldn't impact this -- I'm not saying they
don't, but they damn well shouldn't, rendering for print shouldn't care
about saved/unsaved/multiple references, it should just read what's
available and render.

-MM
 
K

Ken Slovak

Outlook printing is pretty pathetic for the most part. Not much change there
since day 1.

Obviously with VB6 code you wouldn't have the managed code problems,
although you can still get caught by unexpected COM references.

I tend to not use VSTO unless I'm only supporting one or two of the latest
versions only. For everything else I use shared addins and reference the
oldest version of Outlook I want to support.
 
Top