Determine what GC.Collect will throw out

[Fruber Malcome]

I've been working several days to figure out why showing a CustomForm on
Word was causing me problems.
I started to notice that when I removed all the controls and made it a basic
Form, it lasted longer, but eventually it would still kill the code.

I then suspected something else in my code that was probably being garbage
collected, so I use the following lines of code at my document_open
function.

GC.Collect()
GC.WaitFormPendingFinalizers()

Now it seems my code is gone after this, so I assume that when closing the
forms, some garbage collection was going on and at that point it was causing
my application to exit with no exceptions etc.

So my question:

How can I determine what GC.Collect will remove, so that way I can try to
troubleshoot what object is leaving that shouldn't (e.g. some out of scope
variable).

I'm not sure there are any, but I'm just trying to figure it out.

For some additional information: I have a class that has some exposed
document_open and document_close functions that handled all of my word
functionality. I've left the standard template created (by the word wizard
in VSTO) alone and just create an instance of my WordClass (which is a
static member of the OfficeCodeBehind class) in the _Startup.

I pass to it a ref to both the application and document. Those objects are
then set accordingly in my WordClass as members as well. (so that they don't
leave scope).

So I'm not sure if that is the problem, but hopefully this additional
information is helpful to anyone that has seen something like this.

Any help would be really appreciated..
thanks

 

[Fruber Malcome]

I think this idea may be on to something, here is some additional
information:

I know that the GC could have a tendancy to reclaim objects that are in use
of unmanaged code or methods that use COM.

Is it possible that this is what is going on?

Let me better explain my current design:
Take a default Word Document VSTO application created by the wizard.
I then have a .dll (class library that I built using C#) that has both a
Word.Application and a Word.Document member variable that get set in the
constructor of the class in this class library (known as WordClass).

I instantiate an instance of this class via the _Startup function of the
OfficeCodeBehind class.
I do have a static member variable for my WordClass in my OfficeCodeBehind
class.

But the only thing that all this code really accomplishes is the creating
and removing of some Toolbars and Menubars.

I have handlers (in the WordClass library) that handle the click etc events
from these commandbars etc.

It seems that these handlers do get handled up to the point where "some
amount of time has gone by" or "when gcc.collect is called". After this,
none of my handlers run and it seems that my WordClass is no longer around.
(I have no real way to test this - other than the fact that I get the macro
not found error when trying one of my custom menu options).

All the examples I see perform some task in the _Startup function, in my
particular case, the only task is to create an instance of this variable,
then when document_open is called, I just call the document_open public
function of my WordClass and it performs the necessary functions to remove
and add commandbars.

Up to this point every works as planned.

But if I put a GC.collect at the end of my WordClass.document_open function,
none of my handlers work (right away).
If I put a GC.collect at the end of my OfficeCodeBehind.document_open
function, my handlers will work for a few seconds, then they stop. (assuming
after garbage is collected.)

Does anyone have any ideas as to what is leaving memory (going out of scope)
that would cause my handlers to not be handled?
NOTE: I'm using class based member variables on all of this, so I know it's
not a local scope issue. The only thing I haven't tried is making my
WordClass a singleton that's created during the declaration. (because then I
couldn't ensure that the application and document variables were set)

Any help would really be appreciated..

thanks - Fruber