.Net controls not being destroyed when switching pages in a frame

microsoft.public.dotnet.framework

19 Jun 2006 1:12 PM

Kristopher Wragg

Hi,

Currently were moving all our IE hosted java controls over to .NET, we
have a two framed web page, the top frame contains a server client that
receives messages from a server stores various information and also
fires various events to which controls in the lower frame can register
for and act upon.

I've noticed a problem where by when the lower frame loads another web
page that the controls that were hosted in there are still active in
the background. I've registered for the HandleDestroyed event so I can
cut down on a lot of the problems by un-registering for the other
events etc. But the main problem is that it doesn't seem to free up
all the memory those controls were using.

Obviously this is a major concern as if they switch between various
different frames there is going to be a lot of memory being used
without reason.
So I'm just wondering whether there is anything that I need to do when
the handle is destroyed to make it clear up, ie tell the garbage
collector to do its business? What exactly is going off with the
controls hosted in IE's App Domain?

Any information would be greatly appreciated, this product won't be
fit to pass QA if it's eating memory due to .NET / Internet Explorer
not working as we assumed it should.
I spent a couple of minutes switching the bottom frame between
different controls... alarmingly it's increased my page file by over
300mb and creates 5 threads on the IExplore process each switch...
IExplore.exe now has over 400 threads...

Memory usage appears to drop gradually, but the PageFile is not slowly
dropping and neither is the number of threads being used...

How can I monitor what controls are sat in the background effectively
doing nothing and storing memory and have threads attached to them?

I have a feeling the issue may not be to do with .Net's Garbage
Collection but more likely to do with IE not destroying the controls
totally when switching the page in a frame whilst a .Net control is
still hosted in another frame?

Obviously I can't confirm this suspicion as I don't know how IE does
this... but adding 10mb to the Page File and 5 threads to the IExplore
process every time I switch the page in the frame doesn't sound great
to me... end users could have IE open all day and switch views many
many times, how many threads before IE dies? how much will the Page
File take before it causes problems? Will it clear itself? I can't
answer these questions...

Regards,
Kris Wragg