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.
"John Erickson" <JohnErickson> wrote in message
news:16673ACA-5297-41DA-BFED-8817D1D0A54E@microsoft.com...
> 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?
