1. RE: Supercharge your peek_string()
Matthew Lewis wrote:
>
> --- Al Getz <Xaxo at aol.com> wrote:
>
> > This new way of peek'ing a zstring is typically
> > at least 5 times faster then the old way, and its
> > only one line of code 
>
> Actually, the number of bytes are stored in the four bytes before
> the pointer
> to the string.
>
> =====
> Matt Lewis
> http://www14.brinkster.com/matthewlewis
>
>
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?
--Al
2. RE: Supercharge your peek_string()
--- 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
