From: axtens on
G'day everyone

Using CVF 6.6 under Windows XP Pro:

I'm writing a COM DLL. I have two 2D allocatable arrays of VARIANT. In
one routine, I load data into the first array as VT_BSTRs using
SysAllocStringLen. In another routine, I TRANSPOSE that array into the
second 2D array. In a third routine, I store the contents of the
second array into a safearray for passing back to the caller.

The problem I have is that TRANSPOSE seems to mangle the destination
array in a weird way. The addresses that are allocated by
SysAllocStringLen do not change (I've checked that) but what is
pointed to appears to change. I know this because when I call
SysStringLen against ... % VU % PTR_VAL, I get a length that is quite
different to that of the original. What is even more perverse is that
some lengths are correct and some are not.

Below is debug output as the source code is now quite lengthy and
involved (though I'm quite happy to send it to you off-list):

First part (after the [3548] bit) is column, row, address of BSTR, and
number of characters. This is what's in the first 2D variant array.
[3548] 1 1 1652940 2
[3548] 2 1 1652900 2
[3548] 3 1 1652980 2
[3548] 4 1 1654156 2
[3548] 1 2 1653020 2
[3548] 2 2 1653060 2
[3548] 3 2 1698932 2
[3548] 4 2 1764756 2
[3548] 1 3 2230836 2
[3548] 2 3 1698908 2
[3548] 3 3 1698884 2
[3548] 4 3 1698860 2

First part (after the [3548] bit) is column, row, address of BSTR, and
number of characters. This is the second 2D array after having
TRANSPOSEd the first array into it.
[3548] 1 1 1652940 2
[3548] 1 2 1652900 2
[3548] 1 3 1652980 2
[3548] 1 4 1654156 2
[3548] 2 1 1653020 2
[3548] 2 2 1653060 2
[3548] 2 3 1698932 1115416

What I don't understand is why the string at 1698932 is now 115416
characters long when it was 2 characters only milliseconds before.
BTW, there are no values after this because it's at this point the
program crashes.

I'm at a loss to figure out what is happening. Any ideas?

Kind regards,
Bruce.
From: Kurt Kallblad on

"axtens" <Bruce.Axtens(a)gmail.com> wrote in message
news:7536a1c1-04c8-4000-b4f6-77432597059d(a)v1g2000pra.googlegroups.com...
> G'day everyone
>
> Using CVF 6.6 under Windows XP Pro:
>
> I'm writing a COM DLL. I have two 2D allocatable arrays of
> VARIANT. In
> one routine, I load data into the first array as VT_BSTRs using
> SysAllocStringLen. In another routine, I TRANSPOSE that array
> into the
> second 2D array. In a third routine, I store the contents of
> the
> second array into a safearray for passing back to the caller.
>
> The problem I have is that TRANSPOSE seems to mangle the
> destination
> array in a weird way. The addresses that are allocated by
> SysAllocStringLen do not change (I've checked that) but what is
> pointed to appears to change. I know this because when I call
> SysStringLen against ... % VU % PTR_VAL, I get a length that is
> quite
> different to that of the original. What is even more perverse
> is that
> some lengths are correct and some are not.
>
SNIP

> What I don't understand is why the string at 1698932 is now
> 115416
> characters long when it was 2 characters only milliseconds
> before.
> BTW, there are no values after this because it's at this point
> the
> program crashes.
>
> I'm at a loss to figure out what is happening. Any ideas?
>
> Kind regards,
> Bruce.

Hi,

Following from the CVF 6.6 online manual may give some hints.

-----------------
SysAllocStringLen
Note: This function does NOT convert a char * string
into a unicode BSTR. The BSTR returned with this
function can only be used with 16 bit applications.
SysStringLen
Comments
The returned value may be different from _fstrlen(bstr)
if the BSTR was allocated with Sys[Re]AllocStringLen
or SysAllocStringByteLen, and the passed-in characters
included a null character in the first cch characters.
-----------------

If you want to send me the complete source code I have some
time during this weekend to look at it.

Best regards,
Kurt

From: axtens on
On Jul 4, 3:47 pm, "Kurt Kallblad" <kurt.kallb...(a)tele2.se> wrote:

> SysAllocStringLen
>   Note: This function does NOT convert a char * string
>   into a unicode BSTR. The BSTR returned with this
>   function can only be used with 16 bit applications.

That is so weird. In the C++ COM DLLs I've written, I've used
SysAllocStringLen extensively without issue ... unless 16bit here
refers to UTF16 rather than a 16bit processor architecture.

> SysStringLen
>   Comments
>   The returned value may be different from _fstrlen(bstr)
>    if the BSTR was allocated with Sys[Re]AllocStringLen
>    or SysAllocStringByteLen, and the passed-in characters
>    included a null character in the first cch characters.
> -----------------

That's also weird. But thanks for the heads-up all the same.

Bruce.