If I make the following change to oleargs.cpp
--- oleargs.cpp.orig 2007-07-13 11:21:30.711416000 -0400
+++ oleargs.cpp 2007-07-13 11:22:46.764499200 -0400
@@ -834,6 +834,16 @@
if (FAILED(hres))
return PyCom_BuildPyException(hres);
long cElems = ub-lb+1;
+ for(UINT d = dimNo+ 1; d<=nDims; d++)
+ {
+ hres = SafeArrayGetLBound(psa, d, &lb);
+ if (FAILED(hres))
+ return PyCom_BuildPyException(hres);
+ hres = SafeArrayGetUBound(psa, d, &ub);
+ if (FAILED(hres))
+ return PyCom_BuildPyException(hres);
+ cElems *= (ub - lb + 1);
+ }
long dataSize = cElems * sizeof(unsigned char);
PyObject *ret = PyBuffer_New(dataSize);
if (ret!=NULL) {
then I get the full array back, but of course it comes back as an
array of 1 dimension. The original dimension information is lost.
Which leads to the question of what is the correct object to return
in this case.
I don't think that a tuple of buffers, as you describe below, is
really the right thing. For that to work either you have to reverse
the dimension order of the array, or the buffers have to contain data
that originally wasn't contiguous (the buffers hold columns instead
of rows). Neither seems particularly useful.
Would it make sense to return an object thats a buffer that holds the
full array data, but also has some additional attribute that contains
the original array dimensions? For my particular case that would be
the idea, since I want to feed the data into PIL.Image.frombuffer,
which takes a buffer plus a size tuple. But I'm not sure what the
best choice would be for general use.
Also, what is the procedure for building a windows installer for
pywin32? I can't seem to find any documentation on that. I'd like to
create an installer that contains the above patch that I can use
until fix makes it into an offical pywin32 release.
Thanks
-J
On Jul 4, 2007, at 7:35 PM, Mark Hammond wrote:
>> On Jul 4, 2007, at 7:12 PM, Mark Hammond wrote:
>>>
>>> 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
>
_______________________________________________
Python-win32 mailing list
Python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
