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

"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?

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?

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"John Erickson" wrote in message
...
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?

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?

"Ken Slovak - [MVP - Outlook]" wrote:

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"John Erickson" wrote in message
...
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?

Sorry I meant get_Inspector not get_Explorer.

"John Erickson" wrote:

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?

"Ken Slovak - [MVP - Outlook]" wrote:

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"John Erickson" wrote in message
...
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?