Ref leaks

  • Thread starter Thread starter John Erickson
  • Start date Start date
J

John Erickson

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?
 
Sorry. This post was premature. I found a bug in my sink object class that
was causing the problem. Everything works fine now.

John
 
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?
 
There are really 2 scenarios that can come into play here. One is open items
in Inspectors and the other is a selected item in an Explorer being viewed
in the Reading Pane.

In the case of an Inspector you would release all your resources for that
item in the Inspector.Close() event handler. You get a handle to the
Inspector in Inspectors.NewInspector(), set up a handler for Close() and use
that as a release point.

Normally, so we can handle more than 1 open Inspector we use wrapper classes
that encapsulate the Inspector and its item and we handle all events in that
class. The classes are then put into lists/collections/etc. to keep them
alive while the Inspector is open.

In the case of selected items you want to handle the
Explorer.SelectionChange() event. That tells you how many items are selected
and what items (from the Selection collection). When the selection changes
you release your resources for that item.

You can also use Explorer.BeforeFolderSwitch() to know when the user is
changing folders, that allows you decide if you want to handle things in the
new folder.

The Explorer you'd use is the ActiveExplorer() object.
 
Thanks for the quick reply Ken. From Outlook::_FormRegion I see a
get_Explorer method. Can I use that method in both scenerios to hook the
close event?
 
Sorry I meant get_Inspector not get_Explorer.

John Erickson said:
Thanks for the quick reply Ken. From Outlook::_FormRegion I see a
get_Explorer method. Can I use that method in both scenerios to hook the
close event?
Click to expand...
 
The problem with the get* events for Inspector or Explorer are they open a
window of that type if one isn't already opened. If one is opened they use
that. So if something is being read in the preview pane and isn't open,
using get_Inspector() will open the item.

Better to handle NewInspector(), that way you get the handle when the item
is being opened.
 
Thanks to your advise I'm now advising my eventing object at NewInspector and
NewExplorer times so that I can catch the Close() events and clean up. I
still need to tie things together at BeforeFormRegionShow time though. I need
to know at that time if this is being issued for an Explorer or an Inspector
and which instance of which so that I can tie my form region objects to the
appropriate inspector or explorer. That way when the appropriate explorer or
inspector Close()s I can clean up my custom form object as well. The way I am
currently doing that is by doing a pFormRegion->get_Inspector. If that
returns null, than I assume it's being called on behalf of an explorer rather
than an inspector. I then use an Outlook::Application->ActiveExporer call to
determine which (if there can be more than one) explorer this
BeforeFormRegionShow is beind called for. The results of those two calls
allow me to tie my form objects with the appropriate explorer or inspector.
The get_Inspector call doesn't seem to be creating a new Inspector since it
returns null if the BeforeFormRegionShow call is for an explorer. Am I
missing something? Is there a better way to determine who
BeforeFormRegionShow is being called for? Has my custom form already been
added to the explorer or inspector by the time a NewInspector or NewExplorer
call has been made? I assumed not, but if it is I could initialize my custom
form at that time instead of at BeforeFormRegionShow time. But, I dont see a
way to get the _FormRegion object then. It would be nice if the
BeforeFormRegionShow or the _FormRegion object could tell me it's owner. Does
get_Parent return the Explorer or Inspector object the region is for?

John
 
FormRegion.Parent should return the Inspector the form region is associated
with, as should the Inspector property.
 
Back
Top