[python-win32] Garbage collection of dispatched classes withdispatched classes

[Metz, Bobby W, WCS]

Thanks Mark.  I've been using Dispatch which starts new if my user isn't
already active in HelpDesk.  Unfortunately I have to use the same
instance as the user since the add-on I'm writing presents info not
available in HelpDesk based on what the user has selected.  Fortunately
HelpDesk does have a couple of functions that throw a specific COM error
when the user has killed the app but it's still running, so I catch that
error to detect hung state.  Unfortunately, HelpDesk wasn't given a COM
close function...crazy I know.  I didn't know that DispatchEx worked
that way, so thatnks for that.

Bobby

-----Original Message-----
From: Mark Hammond [mailto:mhammond at skippinet.com.au]
Sent: Wednesday, April 05, 2006 1:04 AM
To: Metz, Bobby W, WCS; python-win32 at python.org
Subject: RE: [python-win32] Garbage collection of dispatched classes
withdispatched classes


> 	Hi, I'm hoping someone might provide some COM dispatching
> insights as I'm relatively new to it in Python.  Does using static
> binding provide for better garbage collection when the dispatched
class
> has dispatched classes of it's own?

Nope - it should make no difference.

> The nitty gritty...
>
> 	I'm dispatching a registered class, HelpDesk, from python that
> in turn automates another class, TicketList (has no API that Python
can
> use and there's no support for either class in order to know the full
> details of the interaction).  The ListTicket class provides a portion
of
> the GUI within the HelpDesk GUI the user sees.  Basically, I'm
> automating HelpDesk to pull info from it for my own GUI add-on and
don't
> care about TicketList; however, HelpDesk will always start ListTicket
> and pass information to it and I can't prevent that.  So here's the
> problem situation...
> 	If a user closes the HelpDesk instance I've dispatched, the GUI
> closes but the actual .exe stays running under task man.  This appears
> to happen because my program hasn't yet detected the close and set the
> saved instance var to None.  Sometimes setting it to None under this
> condition even causes an error in the hung HelpDesk .exe which doesn't
> appear as an exception in Python, so I tend to use ProcessTerminate
when
> I detect the hung .exe.  The ListTicket program dispatched by HelpDesk
> no longer appears in task man; however, after I kill the HelpDesk prog
> and re-dispatch a new instance, the interaction between HelpDesk and
> ListTicket doesn't work correctly, i.e. ListTicket prompts the user
for
> a piece of info that has already been provided to HelpDesk, one which
it
> never asks for normally.  Sometimes it even appears that ListTicket
was
> really still running (according to win32process.EnumProcesses).  I'm
> doing dynamic instead of static binding of the HelpDesk class and I
was
> wondering if anyone thought this might be the root cause, i.e. any
ideas
> if using static binding would provide for better garbage collection
when
> the dispatched class has dispatched classes of it's own?

There is no "garbage collection" happening here and it is a tricky
problem
(that may just be a bug in HelpDesk) - you have a reference to the COM
object, and nothing is capable of knowing the app is dead and the
reference
is "invalid".  If you can hook events from HelpDesk, just hook the close
event and release your reference that this point - the app should then
cleanly shut down - otherwise try setting the app to invisible, so the
user
can't close it!  Using win32com.client.DispatchEx() will often start a
second instance of an application where win32com.client.Dispatch() would
reuse an existing one - so you may be able to get your own "private"
instance running...

Mark