|
From: axtens on 2 Jul 2008 11:49 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 4 Jul 2008 03:47 "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 7 Jul 2008 06:31 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.
|
Pages: 1 Prev: error during write Next: Native Fortran 77 - CGI interface howto |