🚀 go-pugleaf

You're right--not a bug in my code--I don't care that far into the HTML 
string--just a bug in your code if you use my code...:)

<<Also, you could do away with the loop altogether by just using 
StringReplace()>>
Yeah, probably could.  Assuming you are right , my misunderstanding.  I 
would have thought the StringReplace would stop at the 0 since I would think 
stringreplace would identify the same end as my object inspector. 
Apparently not true though.
I think what was confusing me is the way the object inspector was showing 
the string--it will stop at the 0.

Anyway--cool--but no kudos for identifying a problem (significant to me 
anyway) and hacking my through it?:)

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:41b41051$1@newsgroups.borland.com...
>
> "Ted Tripp" <ttripp@rankexec.com> wrote in message
> news:41b25214@newsgroups.borland.com...
>
>> OK--my solution--roughly
>
> There is a bug in that code - you are ignoring the AnsiString's last
> character when checking for '\0' characters.  Your loop should be using 
> the
> '<=' operator instead of '<'.
>
> Also, you could do away with the loop altogether by just using
> StringReplace() instead of looping manually.
>
>> Oddly, the asBigString.Length() reported an accurate size
>
> As well it should.  The string returned by TIdHTTP will contains all of 
> the
> transmitted characters, regardless of what they actually are.  The actual
> characters are irrelevant to the transmission, they are stored in the
> AnsiString as-is.
>
>> Not sure why it would truncate the string and then report it a
>> size well past what it considered the end of the string.
>
> The only way that can happen is if your own code is treating the 
> AnsiString
> content as a null-terminated C string rather than a true AnsiString.
>
>
> Gambit
>
>
>