Problem passing COM objects from COM Server to ActiveX Control and back.

[Hannes Grund]

Dear all,

I'm currently developing an application that makes heavy use
of COM objects. I'm struggling with the following Problem:

In short the setup:
Machine: Win2000, python2.2, win32com extensions, wxPython
(The application is aimed to manage a molecule database,
 The COM objects being created via win32com.client.Dispatch(..))

The main actors within the problem:

- A server component that reads molecule data from a propitiery database,
  it is instanciated via win32com.client.Dispatch(PROGID),
  on demand it delivers "Molecule"-Objects which are itself COM objects,
  when returned back by the server these are outlined as <COMObject
<unknown>>
  (i.e. these are NOT build by win32com.client etc. they come out as the
result
  of a function call on the server component)

- An ActiveX Control (from the same vendor, same typelib) aimed to display
  molecules of the above type. This control is integrated in the wxPython
framework
  via the method MakeActiveXClass from "activexwrapper.py".

My problem:

  The control itself exposes a property where a molecule of the above type
  can be assigned (which is displayed then within the control).
  If the property is read afterwards, the molecule has become a
  <win32com.client.gen_py.....instance at ...> which seems to be OK so far.

 This instance can be processed without problems via python or even the
above
 server object. The problem arises when one tries to put this object again
 in the control (via the property, what initially worked). It simply to
refuses
 to show up again.

I guess there are happening many things on the interfaces when passing these
objects
from one component to the other, but I cannot finger out the crucial step.
Furthermore I don't know whether it is really the problem of pythoncom (in a
previous version of the above software suite everything worked well).

Although this seems to be a rather special kind of problem,
any help, hint or advise would be highly appreciated.

Hannes Grund