>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 "