SafeArrayBounds for 2D arrays   

Hi All --

I recently came across something odd and wonder if it's just something I'm doing wrong, or if this is known behavior. I can't find any references that address this.

I have a DLL function that accepts a 2D SafeArray of one type (COLORQUAD, representing a bitmap) and creates and returns a parallel 2D array of a different type.  Since these represent bitmaps, they're almost always non-square (H > V, e.g.).

To create the parallel array, I set aside a block of memory the size of two SAFEARRAYBOUND structures, and copy the same structures from the input array.  I pass this block to SafeArrayCreate and get a successful return.

But the axis (if you will) of the array has twisted: the size of the first dimension in the new array is that of the second dimension in the input array, and vice versa. The BOUND structures are reversed from input to output.

Is this expected, and is it documented anywhere?  Can it be generalized for n-D arrays?

Thanks for any insights.

-- 
        Jim

date: Sat, 11 Feb 2006 08:03:50 -0500   author:   Jim Mack

Re: SafeArrayBounds for 2D arrays   

"Jim Mack"  wrote in message
news:%23FnxbuwLGHA.360@TK2MSFTNGP12.phx.gbl
> I have a DLL function that accepts a 2D SafeArray of one type
> (COLORQUAD, representing a bitmap) and creates and returns a parallel
> 2D array of a different type.  Since these represent bitmaps, they're
> almost always non-square (H > V, e.g.).
>
> To create the parallel array, I set aside a block of memory the size
> of two SAFEARRAYBOUND structures, and copy the same structures from
> the input array.  I pass this block to SafeArrayCreate and get a
> successful return.
>
> But the axis (if you will) of the array has twisted: the size of the
> first dimension in the new array is that of the second dimension in
> the input array, and vice versa. The BOUND structures are reversed
> from input to output.

This is expected. Bounds stored in SAFEARRAY::rgsabound array are in 
reverse order with respect to what was passed to SafeArrayCreate. If you 
read SAFEARRAY::rgsabound directly, you have to account for that. If you 
use SafeArrayLBound and SafeArrayUBound, you get bounds in the "correct" 
order (as originally specified in SafeArrayCreate).
--
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

date: Sat, 11 Feb 2006 14:56:43 -0500   author:   Igor Tandetnik

Re: SafeArrayBounds for 2D arrays   

Igor Tandetnik wrote:
> "Jim Mack"  wrote in message
> news:%23FnxbuwLGHA.360@TK2MSFTNGP12.phx.gbl
>> I have a DLL function that accepts a 2D SafeArray of one type
>> (COLORQUAD, representing a bitmap) and creates and returns a parallel
>> 2D array of a different type.  Since these represent bitmaps, they're
>> almost always non-square (H > V, e.g.).
>> 
>> To create the parallel array, I set aside a block of memory the size
>> of two SAFEARRAYBOUND structures, and copy the same structures from
>> the input array.  I pass this block to SafeArrayCreate and get a
>> successful return.
>> 
>> But the axis (if you will) of the array has twisted: the size of the
>> first dimension in the new array is that of the second dimension in
>> the input array, and vice versa. The BOUND structures are reversed
>> from input to output.
> 
> This is expected. Bounds stored in SAFEARRAY::rgsabound array are in
> reverse order with respect to what was passed to SafeArrayCreate. If
> you read SAFEARRAY::rgsabound directly, you have to account for that.
> If you use SafeArrayLBound and SafeArrayUBound, you get bounds in the
> "correct" order (as originally specified in SafeArrayCreate).

Thanks, Igor.  I suppose there's a valid reason for this, but it escapes me what it could be.

Is this documented anywhere?  It's obviously true, but I would like to read up on it.  Neither MSDN nor OLE2 Programmer's Reference mention this.

-- 
        Jim

date: Sat, 11 Feb 2006 17:17:43 -0500   author:   Jim Mack