#2 RAW returning a VB String


I'm using the VB Binding of Zoom in Javascript.

I've mentioned this problem to Thomas Habing before,
but I think it might be
a good idea to document it in the archives.

The VB binding which returns a raw data record returns
an 8-bit string in a
variant data structure using the following code :-

ptr = zoom_yaz_c_function_getting_pointer

RawData = CVar(CopyString(ptr))

where CopyString eventually calls lstrcpy.

All this is fine!

However when using Javascript the function is called via
IDispatch and COM
and this converts the 8-bit character string into 16-bit
wchar Unicode by
calling an API function which assumes the string is
Windows 1252 (or even
worse 1250 et al.) and converts the characters in the
range hex 80 to 9F
into their Unicode equivalents (and they are NOT the
same values)

The effect is to totally screw up ISO5426 encoding.

Currently I take the Javascript Unicode string, send it to
my application
server where I convert the Unicode back into 8-bit bytes
(currently assuming
Windows1252), extract the MAB data (which is NOT the
same as ISO2709) or
Unimarc data convert the ISO5426 or other like 8898-1
into UTF-8 and build
an XML tree like in Marc21 (or with SUTRS just convert
to UTF-8), send back
to the browser for display (I'm actually using VB Zoom in
IE 6.0 using XML
and XSL).

I have placed a question in

Robert Sanderson wrote "...Z.39.50 is not hard..."

I'd agree, if it weren't for all the options, character set,
possibilites I have to watch out for!


  • Thomas G. Habing

    Logged In: YES

    I'm not a VB programmer. Somebody has written me a bit of
    code that returns a VARIANT from a C string as follows :-

    ptr = some_c_function_returning_pointer
    and then
    VBFunctionName = CVar(CopyString(ptr))

    Clearly this copies the bytes into the variant.

    But I access this function from JavaScript via COM and the
    COM converts the VB variant into a BSTR and in doing so
    executes an ANSI to Unicode conversion which messes up
    all bytes whose hex values are between 80 and 9F. Worse,
    the transformation is Windows version dependant (ie: whether
    the code page is 1250,1252 etc...)

    1) Is there anything I can do to overcome this conversion, so
    that I get one byte per 16-bits in the Javascript string
    WITHOUT altering the program


    2) How would you advise the VB programmer to change the
    function to overcome the problem BUT remain compatible
    with existing VB code (ie: calling the function from within VB)

  • Thomas G. Habing

    Logged In: YES

    I now have to convince Thomas Habing to ensure that the
    rawData to Javascript either returns a Javascript/VBScript
    array, or that the string returned has NOT gone through an
    ISO-8898-x to UTF-16 conversion.

  • Thomas G. Habing

    Logged In: YES

    Extensive comments about this issue at Experts Exchange:


  • Thomas G. Habing

    Logged In: YES

    I'm convinced I need to support returning raw data as a VB
    Byte Array. I am thinking of adding a property named
    something like 'ReallyRawData' or 'RawDataByteArray' which
    returns the raw data as a byte array. I am hesitant to change
    how the current RawData property works so as not to break
    anyone's current applications.

    Does anyone have any comments or preferred names for the
    new property returning a byte array? Or, should I just bite the
    bullet and make RawData return a byte array and document
    how existing apps will need to be modified, possibly using the
    StrConv function on the returned byte array?

    Another idea would be to add an optional param to the
    RawData method which specifies the return type, with the
    default being String:

    vbarr = rec.RawData(RETURN_BYTE_ARRAY) or str =

  • Thomas G. Habing

    Logged In: YES

    Thanks for the ideas, and words of encouragement. I think for
    starters I
    will get the VARIANT array of byte working, then if there still
    seems to be
    a need, I may play around with constructing my own BSTR.

    Regarding the utility of COM objects: Some people seem to
    be using VB ZOOM
    from Perl on windows as well, see

    Kind regards,

    Jonathan Rowell wrote:
    > ZOOM API VB Binding
    > Dear Thomas,
    > your Visual Basic Binding is in fact far more powerful than it
    > appears. Because Visual Basic 6 automatically produces
    two interfaces per
    > object (one for the object itself and an IDispatch in addition)
    > resultant COM object in the dll is also a C++, VB Script,
    Javascript and
    > Delphi binding. Indeed since one can connect Java to COM
    one could also use
    > the thing in a Java environment. Of course only on Windows!
    > The two interfaces automatically provided are used for what
    Microsoft calls
    > early- and late-binding. In early binding the types of the
    parameters for
    > the call are determined at compile time and must match
    within the usual
    > coercion rules. This happens primarily in VB, C++, Delphi
    and in VBA script
    > where the type of the object is explicitly stated. In
    Javascript and in VBA
    > with plain objects, the call is completely evaluated at run
    time with the
    > effect that the parameters are forcibily coerced to the
    correct type. Indeed
    > string parameters are copyed in on call and back out again
    on return.
    > Since the script languages use 16-bit BSTRs the coercion
    from char+ uses a
    > Windows-12xx-to-UTF-16 character set table where xx is
    the operating system
    > locale. This conversion is NOT the same as widening byte
    to word.
    > There are two possibilities for a correction (which I agree
    should be
    > augmentive) :-
    > 1. Return a VARIANT array of byte
    > This would be in strict accordance with the specification,
    and a little
    > awkward to handle in Scripts.
    > 2. Return a self constructed BSTR which is a byte to word
    > This is not in accordance with the specification, but is
    easy in scripts
    > to work with. So far nobody has come up with the idea of
    checking the
    > legality of the characters.
    > Hope that helps
    > Rat

  • Thomas G. Habing

    • status: open --> closed
  • Thomas G. Habing

    • milestone: --> vb-zoom
  • Nobody/Anonymous

    I am not sure where you are getting your information, but good topic. I needs to spend some time learning much more or understanding more. Thanks for wonderful info I was looking for this info for my mission.
    clearance ugg uk http://uggbootsclearances.webeden.co.uk/

  • Nobody/Anonymous

    Their Miu Miu Online http://miumiuonline.v5s7.com seemed to be pleasing coupled with pleasing.

  • Nobody/Anonymous

    I enjoy these kinds of Celine Online http://celineonline.v5s7.com! At the beginning I was too embarrassed the color I just ordered was in fact too light- sand nonetheless was given these at present additionally they had been the best colors! I will be fairly gratified and that i won't be able to delay to generate these on a daily basis :Deb!


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks