Nope, I am still having a problem here... I'm still having issues with events
that I can't explain. My addin is (among other things) hooking into
_FormRegionStartup, adding a Custom Form Region to the reading pane and to
any Inspector windows that might popup. Here's the scenerio:

1. Start Outlook
2. Select Inbox causing the reding pane to attempt to show it.
3. My GetFormRegionStorage method is called and I return a safe array that I
pulled out of my resource file containing the custom ofs file.
4. My BeforeFormRegionShow method gets called and I track down my first
control (an Outlook:OlkOptionButton) and create a sink object for its
Outlook::OlkButtonEvents. At this time I retain a reference to the IUnknown
of the control in hopes that if the control gets re-used (vs. being recreated
each time it's needed), that I will be able to detect its re-use by comparing
the IUnknown pointers to see if it's the same control that I already have an
event sinked to. I also Addref this IUnknown so that it won't go away until
I've had a chance to remove my event handler.
5. All is fine so far, now is where the problem starts. For this step I
select another mail item in my Inbox causing the reading pane to refresh.
6. My GetFormRegionStorage gets called again and I pass it my custom OFS. I
would expect it to re-use the form that I already passed it last time and not
have to reload it each time a new mail item is displayed in the reading pane.
But that's just a perf issue. Fine... it's re-creating my custom form region
again. But if that's the case, and the old one was destroyed, why didn't it
release my event handler that I had connected to the old control? It did a
Query interface on my IDispatch in step 4. That would imply that it has a
reference to my event handler and all it's resources. Had it called release I
could have freed up all my resources associated with that event handler.
Since it didn't, that event handler and all it's resources are hanging around
until Outlook terminates or until I unadvise that event handler. It does
release the reference from the QI if I call unadvise (which I do at my
program termination (IDTExtensibility2::OnDisconnection)). So that might not
be too bad. Maybe it's by design and if I go back to my original message that
was displayed it will re-use the already created custom form for that
message. That's not the case. If I go back to the first message, it still
re-creates a new custom form for that message. Now I have two event handlers
for controls in my custom form for the same message. During shutdown, I end
up Unadvising any and all connections to controls that have been established
during navigating around various messages in my inbox. If I have visited 5
mail items, then I end up unadvising 5 event handlers. If I've looked at 1000
messages, I end up Unadvising 1000 events hooked to controls that seem to be
still hanging around. At least they Release me when I Unadvise them to.

So the question is... How can I detect when Outlook is done with my custom
form and I can release all the resource associated with that control?

"John Erickson" wrote:

Sorry. This post was premature. I found a bug in my sink object class that
was causing the problem. Everything works fine now.

John

"John Erickson" wrote:

Hi,

I am developing a new Outlook addin that adds a new form region to the
reading pane and the inspector windows. I noticed that the advise() call I
make to hook up the events for the fields on my form result in a
QueryInterface of my Sink Object which results in its ref count being
increased, but I never see a Release() call come back for my event object.
How do I know when I can get rid of my event sink object? Also, it appears
that when I change my selection from one mail item to another my form gets
destroyed and a new one is created that I have to hook up the events to
again. Why don't I see Release() calls on my old event sinks when that
happens? Is it leaking more than just the ref counts when this happens? I
know I need to have multiple event sink objects hanging around for my form
interaction (One for the reading pane and one for every Inspector that is
running) How can I tell when these objects can safely go away without proper
ref counting?