[python-win32] Arrays in Python Com servers

[Craig Taverner]

Thanks Mark,

I got the arrays returned OK now, just by not specifying the type in the
VB DIM statement (ie. "Dim a()" followed by "a=interface.GetArray()").
But one strange thing is that after this, UBound(a) is always one too
short. I have to over-dimension the array in the python COM server by 1
element to have everything line up (it's the last element that is
dropped in VB - perhaps VB uses the end of the array to store extra
array info?).

On the second question:- I was not able to find anything on firing win32
events from the python server in the places you suggested. I only found
info on handling events in python. Is there anywhere else I can get
information on firing events?

What I'm after, to be precise, is the following:
- VB code implements some event handler
- VB code calls interface.StartCalc() on python Com object
- This method does not block, but starts a thread that does some
calculation
- when the calculation is finished, the python fires an event that
either:
	- sends the result array to the VB
		or
	- triggers the VB to call back into python for the result array

Is this even possible in pythoncom? I'm concerned that this might
require implementing some unknown interface and python does not support
that.

Cheers, Craig 

> -----Original Message-----
> From: Mark Hammond [mailto:mhammond at skippinet.com.au]
> Sent: den 3 maj 2003 13:17
> To: 'Scott Prive'; Craig Taverner; python-win32 at python.org
> Subject: RE: [python-win32] Arrays in Python Com servers
> 
> > I suggest Mark's book, Python Programming  on Win32. There is
> > quite a bit on
> > dealing with COM.
> > I am only 100 pages into the book, so I can't comment too much.
> 
> Thanks :)  It should simply be a matter of returning a list (not
tuple) of
> floats from your function.  As there is no typelib, everything is
dynamic,
> so should "just work" using any compatible type in the array you
choose.
> 
> > Did you mean win32 events? I don't see that in the book
> > anywhere (and I
> > could be wrong). There have been some message threads on this
> > subject I've
> > seen in the mail archives.
> 
> Unfortunately, event support missed the book.  Fortunately it isn't
that
> hard - see the docstrings for win32com.client.DispatchWithEvents, or
> win32com\test\test_*events*
> 
> Mark.