I haven't checked carefully, but I believe the J server bugs with BSTR lengths were fixed in the 601 release. At quick check shows no differences in that area between 601 and 602.

Your example with SysAllocStringLen is correct that a null is always at the end of a BSTR memory allocation and although part of the memory allocated is not included in the BSTR length count.

I think (but haven't checked) that the integer count preceeding the BSTR pointer is in fact a byte count and not a wchar count. That is, in your 'test' BSTR example the value in the preceeding length is 8, not 4.

There were some changes in the J server and these are documented in
Help|User Manual|COM, OLE, and OCX|J OLE Automation Server

The important change is that the sentences necessary to load profile and get an ijx window are different than in 601. These differences are due to the changes in the area of bin folder, BINPATH, etc.

----- Original Message ----- From: "Oleg Kobchenko" <[EMAIL PROTECTED]>
To: "Beta forum" <[email protected]>
Sent: Sunday, February 03, 2008 1:16 AM
Subject: Re: [Jbeta] VB COM Interface


Here's a message supposed to be sent to JForum in 2004,
but don't see it in forum archive.

So the idea is that perhaps your code compensated
for the extra \0 at the end of BSTR.

--- Oleg Kobchenko <[EMAIL PROTECTED]> wrote:

Date:         Fri, 9 Jul 2004 03:35:22 -0400
From:         Oleg Kobchenko <[EMAIL PROTECTED]>
Subject: Re: Passing Strings to OCX / ActiveX Controls
To:           [EMAIL PROTECTED]
CC:           Oleg Kobchenko <[EMAIL PROTECTED]>

BSTR for 'test' is stored like this (space per byte):

+----+--+--+--+--+--+
|4   |t |e |s |t |\0|
+----+--+--+--+--+--+
     ^---- pointer

However it should be allocated indirectly using SysXXX:

 DWORD len = wcslen(L"test");
 BSTR s = SysAllocStringLen(L"test", len);

Which will allocate len*2 + 6 bytes, store len
in the first 4 bytes, copy len shorts afterwards,
store \0 in the last short, and return
a pointer to the first character.

However, what has been seen in the examples is (because
BSTR stores length, it can embed null characters)

+----+--+--+--+--+--+--+
|5   |t |e |s |t |\0|\0|
+----+--+--+--+--+--+--+
     ^---- pointer

not what is expected by COM rules.


On Mon, 5 Jul 2004 11:11:07 +0800, Alex Rufon <[EMAIL PROTECTED]>
wrote:

>Hi Simon/Everybody,
>
>I just got back from China so it's the first time I saw this post. I
>also encountered this before so I made a test app to try it again.
>
>In the attached zip file are:
>1. StringTest.DLL - the DLL to be called by the J script. For the non VB
>savvy, its similar to an OCX.
>2. stringtest.ijs - the J script that acts as a wrapper to
>StringTest.DLL 3. jtestvb.JPG - a screenshot of my VB IDE while
>debugging the test. You can see J session at the back of VB.
>4. Various VB files - so you can recompile the thing yourself with VB6.
>;)
>
>So to make a long story short, J did not add an extra space at the end
>of the string but instead added a 0 (or in C notation a \0 ). I think
>this has something to do with how J handles strings ... as zero
>terminated character arrays. :)
>
>Can we consider this as a bug? I actually don't know ... you see I've
>been lucky since I have never consciously called a 3rd party DLL/OCX
>without making a VB or C/C++ wrapper between the 3rd party object and J.
>What I'm saying is that if it becomes a problem, I'll just strip it off
>myself. Unfortunately, I do recognize that there may be cases (for me or
>other J developers) to not be able to do what I normally do.
>
>r/Alex
>
>-----Original Message-----
>From: Simon Gibbon [mailto:[EMAIL PROTECTED]
>Sent: Saturday, July 03, 2004 6:19 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [Jforum] Passing Strings to OCX / ActiveX Controls
>
>Thanks to everybody who posted helpful suggestions, I got in touch with
>the developer of TwainControlX, sent him J and my script.  To cut a long
>story short, he discovered that J sends an extra space at the end of the
>string which it passes to the ActiveX control, hence it did not
>recognise .jpg correctly. He has added code to remove the space and now
>all works wonderfully.
>
>I guess this is a bug with J?  But I equally guess his code was not as
>robust as it could have been.





____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to