[python-win32] win32com array handling bug?

[Mark Hammond]

> On Jul 4, 2007, at 7:12 PM, Mark Hammond wrote:
> >>>>>
> >>
> >> At this point f should be a 2048 by 1536 array of bytes, but
> >> instead...
> >>
> >>>>> len(f)
> >> 2048
> >>>>> type(f)
> >> <type 'buffer'>
> >
> > Arrays of type VT_UI1 are returned as buffers.  You should
> find the
> > length
> > of f is 1536, and you can treat it as a string (ie, just
> index into
> > it to
> > fetch the values, len() to get the length, slice it, etc).  This is
> > primarily done as an optimization, so we don't need to waste time
> > and space
> > building lists of lists of integers when the data is more
> naturally a
> > 'string of bytes' anyway.
> >
> > Mark
> >
>
> I don't quite follow.
>
> I understand (well, I think I understand) how a buffer works. The
> problem is that the length is wrong.
>
> As shown above, the length of f is 2048. If the array was being
> returned correctly
> as a buffer, then the length should be 3145728 (2048 * 1536).

Hrm - I misunderstood.  a 2048x1536 array of bytes *should* be returned as a
list with 2048 entries, each being a buffer of size 1536.  I guess I'll need
to try and reproduce this in the test suite...

Mark