>on 8/31/03 10:40 PM, Jay Reeve at jayreeve@... wrote:
>
>>  Is this an issue of cstrings vs. pstrings? Pstrings (FB) begin with a
>>  length byte and are limited to 255 chars. Cstrings have no length
>>  byte and continue until a CHR$(0) is reached, eliminating the
>>  255-char limit. If Delphi is expecting cstrings, that is likely the
>>  problem.
>>
>>  Converting pstrings to cstrings is easy (providing there are no 0
>>  chars in the string), but the reverse is complicated by the
>>  possibility of lengths > 255, which are impossible to convert
>>  directly to pstrings.
>
>
>Jay,
>
>Thanks for these thoughts.   I did check, to be sure, and my strings are all
>Pascal, with the length byte at the beginning.   I am thinking that if all
>integers are flipped (high-low) then probably the length byte is bogus and
>fouling up the nest.
>
>I have no idea how to "correct" the length byte if this is the problem.
>
>I could try cstrings which is also possible in Delphi, so perhaps that it
>the technique.  The strings are so imbedded I would have to make this a FN
>and I find that the 32K limit in a FN can be a problem here.
>--
>Best Wishes,
>
>George

What happens if you don't put the strings through the high-low 
flipper? I'm not sure it's necessary, as we're not dealing with 
2-byte integers.

Can you find a way to look at the data you're processing in the 
debugger or in Macsbugs? That would likely show you what you are 
dealing with. For example:

Load the file into a handle, txtH, then

CALL DEBUGSTR(";dm "+HEX$([txtH]))

This should show you what's there. Once you know that, you can 
probably figure out how to deal with it.

  e-e
  =J= a  y
   "