RE: Supercharge your peek_string()

new topic     » goto parent     » topic index » view thread      » older message » newer message

--- Al Getz <Xaxo at aol.com> wrote:

> Hi Matt,

> I couldnt establish a relationship between the four bytes preceding
> the lpString and the length of the string, other then a loose one.
> I tried a few times or so and didnt get reasonable results.
> Heres basically what i tried:
> 
> atom lpString, Possibly_Length_Of_String
> sequence text
> 
> text="this string"
> lpString=allocate_string(text)
> Possibly_Length_Of_String=peek4u(lpString-4)
> ?length(text)
> ?Possibly_Length_Of_String
  
> Is this what you were talking about?
> I always get two different numbers printed out.
> Changing the length of the string by one character
> doesnt always even change the second value printed out.
> 
> Is there another trick to it?

Yes, there is another trick.  First is that a bstring is unicode, so you can't
use allocate_string like normal.  First you have to convert to unicode (see
WideToMultiByte / MultiByteToWide, I think), and you have to manually store the
length of the string.  Of course, the tricky thing is that you have to remember
that the length is in bytes, not characters (since unicode chars are 2 bytes).

Lots of COM interfaces use bstrings, so I wrapped a few features in unicode.ew
(part of EuCOM).  So for wide strings, as they are called, you have to look for
a double-zero, which is why I think bstrings were created.

The functions I wrote are alloc_bstr(), peek_bstr(), ansi_to_unicode() and
unicode_to_ansi().



=====
Matt Lewis
http://www14.brinkster.com/matthewlewis

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu